Elektronische Gesundheitskarte und Telematikinfrastruktur





Übergreifende Spezifikation

Performance und Mengengerüst TI-Plattform


    
Version 2.26.2
Revision 574294
Stand 10.02.2023
Status freigegeben
Klassifizierung öffentlich
Referenzierung gemSpec_Perf

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung
2.2.0 02.08.17 Überarbeitung zum Online-Rollout (Stufe 2.1) gematik
Errata 1.6.4-1, 1.6.4-2 und P15.1
2.3.0 18.12.17 Einarbeitung der Änderungen zu OPB1 Release 1.6.4-0, der Errata 1.6.4-1 und 1.6.4-2 und Änderungen zur Version 2.2.0 gematik
2.4.0 14.05.18 Einarbeitung Änderungslisten P15.2 und P15.4 gematik
2.5.0 26.10.18 Einarbeitung Änderungslisten P15.8 und P15.9 gematik
2.6.0 18.12.18 ePA-Inhalte gematik
2.7.0 15.05.19 Einarbeitung P18.1 gematik
2.8.0 28.06.19 Einarbeitung von P19.1 gematik
2.9.0 2.10.19 Einarbeitung von P20.1/2, 16.1/2 gematik
2.9.1 15.11.19 4.5 Afo A_15208 wieder ergänzt gematik
2.10.0 02.03.20 Einarbeitung von P21.1 gematik
2.11.0 30.06.20 Anpassungen gemäß Änderungsliste P22.1 und Scope-Themen aus Systemdesign R4.0.0 gematik
2.12.0 12.11.20 Anpassungen gemäß Änderungsliste P22.2 und Scope-Themen aus Systemdesign R4.0.1 gematik
2.12.1 19.02.21 4.5 red. Anpassung zur R4.0.2 gematik
2.12.2 06.04.21 Einarbeitung KIM_Maintenance_21.1 gematik
2.13.0 14.06.21 Einarbeitung E-Rezept_Maintenance_21.1 und _21.2 sowie
Einarbeitung IdP_Maintenance_21.1
gematik
2.13.1 02.09.21 ab Release "Konnektor PTV 5.0.2: Maintenance 21.5" (Sept. 2021) führt die gematik eine stufenweise Umbenennung folgender Begriffe durch:
aus "aAdG-NetG" wird "WANDA Basic",
aus "aAdG" und "aAdG-NetG-TI" wird "WANDA Smart"
gematik
2.14.0 07.10.21 Einarbeitung gemF_APOVZD  gematik
2.15.0 17.12.21 Einarbeitung IDP 2.3.0 (inkl. entsprechender Anteile aus gemF_sektorale_IDP); Start der strukturellen Anpassungen der produkttypspezifischen Vorgaben (betrifft Kapitel 3, 4 und 5)  gematik
2.16.0 31.01.22 Einarbeitung Konn_Maintenance_21.6 gematik
2.17.0 14.02.22 Einarbeitung Konn_Maintenance_21.6 gematik
2.18.0 31.03.22 Einarbeitung E-Rezept_Maintenance_21.3 (C_10752) und _21.4 gematik
2.19.0 03.05.22 Anteile aus gemF_eRp_WF_LE übernommen gematik
2.20.0 06.05.22 2.5.1
3.1.2.2
Einarbeitung Änderungsliste Rohdaten_Performance_22.1
redaktionelle Änderung in der Bezeichnung des Operationsnamen in Tabelle 6: ALT: "external authentication" NEU: "third-party-based"
gematik
2.21.0 18.05.22
2.5.1, 3.2
Einarbeitung Änderungsliste IDP_Maintenance_22.1;
redaktionelle Änderung: Anpassung der Verweise auf Anforderung A_19733-xx unter Verwendung einer Wildcard: -* 
gematik
2.22.0 29.07.22 3.3, Anhang C TI-Messenger 1.1.0: Festlegungen zu Performance und Reporting gematik
2.23.0 09.08.22 4.2.5, 5.6, Anhang C Einarbeitung Änderungsliste E-Rezept_Maintenance_22.2 und E-Rezept_Maintenance_22.3 und gemF_eRp_PKV gematik
2.24.0 26.08.22 Einarbeitung CI_Maintenance_22.4: Verpflichtung der TSP X.509 auf die Rohdatenlieferung v.02 und damit verbunden die Herauslösung aus der Rohdatenlieferung v.01, erstellen eines TSP X-509-spezifischen Unterkapitels (Kapitel 3.4) gematik
2.25.0 16.12.22 Einarbeitung CI_Maintenance_22.6: Verpflichtung der VPN-Zugangsdienste auf die Rohdatenlieferung nach Version 0.2 für die Betriebsdatenerfassung gematik
2.26.0 06.02.23 Einarbeitung gemäß Änderungslisten E-Rezept_Maintenance_ 22.5, Betr_Maintenance_22.3 und IDP_Maintenance_22.2 gematik
2.26.1 07.02.23 Afo A_22357-03 wird ergänzt und Afo A_18018 angepasst gematik
2.26.2 10.02.23 A_22012-02, A_22825, A_22826, A_22944 hinzugefügt, A_22012-01 und A_22230 abgelöst

Inhaltsverzeichnis

  • Dokumentinformationen
  • Inhaltsverzeichnis
  • : 1 Einordnung des Dokuments
  • : : 1.1 Zielsetzung
  • : : 1.2 Zielgruppe
  • : : 1.3 Geltungsbereich
  • : : 1.4 Abgrenzung des Dokuments
  • : : 1.5 Methodik
  • : : : 1.5.1 Anforderungen
  • : 2 Performance-Kenngrößen und ihr Einsatz
  • : : 2.1 Bearbeitungszeit
  • : : 2.2 Last
  • : : 2.3 Verfügbarkeit
  • : : 2.4 Einsatz der Performance-Kenngrößen
  • : : 2.5 Performance-Evaluierung auf der Basis von Rohdaten
  • : : : 2.5.1 Rohdaten-Performance-Reporting (Rohdatenerfassung v.01)
  • : : : 2.5.2 Rohdaten-Performance-Reporting (Rohdatenerfassung v.02)
  • : : : : 2.5.2.1 Umfang
  • : : : : 2.5.2.2 Lieferintervalle
  • : : : : 2.5.2.3 Format
  • : 3 Produkttypspezifische Vorgaben
  • : : 3.1 IDP-Dienste
  • : : : 3.1.1 Leistungsanforderungen IDP-Dienste
  • : : : : 3.1.1.1 Lastmodell IDP-Dienste
  • : : : : 3.1.1.2 Bearbeitungszeiten IDP-Dienste
  • : : : : 3.1.1.3 Performancevorgaben IDP-Dienste
  • : : : 3.1.2 Rohdaten-Performance-Reporting Spezifika IDP-Dienste
  • : : : : 3.1.2.1 Spezifika Umfang IDP-Dienste
  • : : : : 3.1.2.2 Spezifika Format IDP-Dienste
  • : : : 3.1.3 Bestandsdaten sektoraler IDP
  • : : 3.2 E-Rezept
  • : : : 3.2.1 Leistungsanforderungen E-Rezept
  • : : : : 3.2.1.1 Lastmodell E-Rezept
  • : : : : 3.2.1.2 Bearbeitungszeiten E-Rezept
  • : : : : 3.2.1.3 Performancevorgaben E-Rezept
  • : : : 3.2.2 Rohdaten-Performance-Reporting Spezifika E-Rezept
  • : : : : 3.2.2.1 Umfang
  • : : : : 3.2.2.2 Format
  • : : : 3.2.3 Bestandsdaten
  • : : 3.3 TI-Messenger (TI-M)
  • : : : 3.3.1 Verfügbarkeit
  • : : : 3.3.2 Rohdaten
  • : : 3.4 TSP X.509
  • : : : 3.4.1 Leistungsanforderungen TSP X.509
  • : : : : 3.4.1.1 Lastmodell TSP X.509
  • : : : : 3.4.1.2 Bearbeitungszeiten TSP X.509
  • : : : : 3.4.1.3 Performancevorgaben TSP X.509
  • : : : 3.4.2 Rohdaten-Performance-Reporting Spezifika TSP X.509
  • : : : : 3.4.2.1 Umfang
  • : : : : 3.4.2.2 Format
  • : : 3.5 IDP-Federation Master
  • : : : 3.5.1 Leistungsanforderungen IDP-Federation Master
  • : : : : 3.5.1.1 Lastmodell IDP-Federation Master
  • : : : : 3.5.1.2 Bearbeitungszeiten IDP-Federation Master
  • : : : : 3.5.1.3 Performancevorgaben IDP-Federation Master
  • : : : 3.5.2 Rohdaten-Performance-Reporting Spezifika IDP-Federation Master
  • : : : : 3.5.2.1 Spezifika Umfang IDP-Federation Master
  • : : : : 3.5.2.2 Spezifika Format IDP-Federation Master
  • : : 3.6 VPN-Zugangsdienst
  • : : : 3.6.1 Leistungsanforderungen VPN-Zugangsdienst
  • : : : : 3.6.1.1 Lastmodell VPN-Zugangsdienst
  • : : : : 3.6.1.2 Bearbeitungszeiten VPN-Zugangsdienst
  • : : : : 3.6.1.3 Performancevorgaben VPN-Zugangsdienst
  • : : : 3.6.2 Rohdaten-Performance-Reporting Spezifika VPN-Zugangsdienst
  • : : : : 3.6.2.1 Umfang
  • : : : : 3.6.2.2 Format
  • : 4 Leistungsanforderungen für Anwendungsfälle
  • : : 4.1 Spitzenlasten für Anwendungsfälle
  • : : : 4.1.1 Mengengerüst
  • : : : 4.1.2 Versichertenstammdatenmanagement (VSDM)
  • : : : 4.1.3 Kommunikation Leistungserbringer (KOM-LE)
  • : : : 4.1.4 Notfalldaten-Management (NFDM)
  • : : : 4.1.5 eMP/AMTS-Datenmanagement
  • : : : 4.1.6 Elektronische Patientenakte (ePA)
  • : : : 4.1.7 Tokenbasierte Authentisierung (TBAuth)
  • : : : 4.1.8 Lastmodell auf Ebene der Anwendungsfälle
  • : : : 4.1.9 Betriebliche Anwendungsfälle
  • : : 4.2 Bearbeitungszeiten
  • : : : 4.2.1 Bearbeitungszeiten KOM-LE
  • : : : 4.2.2 Bearbeitungszeiten Notfalldaten-Management (NFDM)
  • : : : 4.2.3 Bearbeitungszeiten eMP/AMTS-Datenmanagement
  • : : : 4.2.4 Bearbeitungszeiten elektronische Patientenakte (ePA)
  • : : : 4.2.5 Bearbeitungszeiten Tokenbasierte Authentisierung
  • : : 4.3 Verfügbarkeiten
  • : 5 Leistungsanforderungen an die Produkttypen der TI
  • : : 5.1 Produkttypen der dezentralen Zone der TI-Plattform
  • : : : 5.1.1 Produkttypen eGK, HBA, SMC-B, SMC-K, SMC-KT
  • : : : 5.1.2 Produkttyp Konnektor
  • : : : : 5.1.2.1 Fachmodul ePA
  • : : : 5.1.3 Produkttyp eHealth-Kartenterminal
  • : : : 5.1.4 Produkttyp Mobiles Kartenterminal
  • : : : 5.1.5 Produkttyp KTR-AdV
  • : : 5.2 Produkttypen der zentralen Zone der TI-Plattform
  • : : : 5.2.1 Produkttyp Verzeichnisdienst
  • : : : 5.2.2 Produkttyp Konfigurationsdienst
  • : : : 5.2.3 Produkttypen der PKI – TSL-Dienst
  • : : : 5.2.4 PKI-Komponenten – OCSP-Responder / CRL-Dienst
  • : : : 5.2.5 Produkttyp TSP-X.509nonQES (Komp) - Provisioning/Revocation
  • : : : 5.2.6 Produkttyp Störungsampel
  • : : : 5.2.7 Produkttyp Service Monitoring
  • : : : 5.2.8 Produkttyp Namensdienst
  • : : : 5.2.9 Produkttyp Zeitdienst
  • : : : 5.2.10 Produkttyp Zentrales Netz der TI
  • : : : 5.2.11 Produkttyp VPN-Zugangsdienst
  • : : : 5.2.12 Produkttyp Sicherheitsgateway Bestandsnetze
  • : : : 5.2.13 Produkttyp Signaturdienst
  • : : : 5.2.14 Produkttyp Schlüsselgenerierungsdienst
  • : : : 5.2.15 Produkttyp IdP-Dienst
  • : : 5.3 Produkttypen VSDM
  • : : : 5.3.1 Produkttyp VSDM Intermediär
  • : : : 5.3.2 Produkttypen Fachdienste VSDM (UFS, VSDD, CMS)
  • : : 5.4 Produkttypen KOM-LE
  • : : : 5.4.1 Produkttyp KOM-LE-Clientmodul
  • : : : 5.4.2 Produkttyp KOM-LE-Fachdienst
  • : : 5.5 Produkttyp ePA-Aktensystem
  • : : 5.6 Produkttyp APOVZD
  • : : : 5.6.1 Verfügbarkeit
  • : : : 5.6.2 Last
  • : : : 5.6.3 Antwortzeiten
  • : : : 5.6.4 Bereitstellung Betriebsdaten
  • : 6 Anhang A – Verzeichnisse
  • : : 6.1 Glossar
  • : : 6.2 Abbildungsverzeichnis
  • : : 6.3 Tabellenverzeichnis
  • : : 6.4 Referenzierte Dokumente
  • : : : 6.4.1 Dokumente der gematik
  • : : : 6.4.2 Weitere Dokumente
  • : 7 Anhang B – Modelldetails
  • : : 7.1 Verteilung der Konnektorbearbeitungszeiten auf Komponenten
  • : 8 Anhang C – Performance-Berichtsformate
  • : 9 Anhang D – Performancerelevante Produktmustereigenschaften des QES-Konnektors
  • : 10 Anhang E – Testverfahren zur Prüfung der Skalierungsfähigkeit des QES-Konnektors
  • 1 Einordnung des Dokuments

    1.1 Zielsetzung

    Die Performance-Spezifikation hat zum Ziel, die Performance-Kenngrößen für alle Produkttypen der TI zu definieren und die Anforderungen an die Performance der Produkttypen zu stellen. Ausgangspunkt für die Berücksichtigung des Bedarfs sind die Leistungsanforderungen für die Fachanwendungen, das sichere Übermittlungsverfahren KOM-LE, die Basisdienste QES, die tokenbasierten Authentisierung sowie für den Zugang zu Fremdnetzen (Internet, Bestandsnetz).

    Die Performance-Kenngrößen decken drei Dimensionen ab:

    Die Ableitung der Produktanforderungen erfolgt über ein Performance-Modell, das hier soweit skizziert wird, wie für die Nachvollziehbarkeit erforderlich.

    Die Anforderungen an die Produkttypen sind so formuliert, dass sie dem Stand der Technik entsprechende Optimierungen implizit voraussetzen, aber nicht zwingendermaßen Vorgaben für konkrete Optimierungen machen. So wird das gewünschte Leistungsniveau erreicht, ohne dabei den Lösungsraum für die Anbieter unnötig einzuschränken. Spezifische Anforderungen zur Optimierung können allerdings in den produkttypspezifischen Spezifikationen gestellt werden.

    1.2 Zielgruppe

    Das Dokument richtet sich an Hersteller und Anbieter von Produkten der TI.

    1.3 Geltungsbereich

    Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens.

    Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

    Schutzrechts-/Patentrechtshinweis

    Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

    1.4 Abgrenzung des Dokuments

    Das vorliegende Dokument stellt Performance-Anforderungen an die technischen, aber nicht an organisatorische Schnittstellen der TI-Plattform.

    1.5 Methodik

    1.5.1 Anforderungen

    Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

    Sie werden im Dokument wie folgt dargestellt:

    <AFO-ID> - <Titel der Afo>
    Text / Beschreibung
    [<=]

    Dabei umfasst die Anforderung sämtliche innerhalb der Afo-ID und der Textmarke angeführten Inhalte.

    2 Performance-Kenngrößen und ihr Einsatz

    Das vorliegende Kapitel definiert die Performance-Kenngrößen für die drei Performance-Dimensionen Bearbeitungszeit, Last und Verfügbarkeit. Außerdem legt es fest, welche Kenngrößen 'reported' werden. 

    2.1 Bearbeitungszeit

    Bearbeitungszeit bezeichnet die Zeit, welche für die Ausführung einer Funktion, sei es auf Anwendungsfallebene oder auf Ebene einer Operation an den technischen Schnittstellen eines Produkttypen anfällt.

    Die auf Ebene der Anwendungsfälle gemessene Bearbeitungszeit, wird der funktionalen Zerlegung und Systemzerlegung des Gesamtsystems folgend, in Bearbeitungszeiten gemessen an den Außenschnittstellen der Produkttypen zerlegt. Dabei kommt es auf eine möglichst exakte und lückenlose Definition der einzelnen Zeitbeiträge an:

    Die Abarbeitung eines Funktionsaufrufs kann durch die Parallelisierung von Teilschritten beschleunigt werden. Die Verarbeitungszeit entlang des Pfades durch die Teilschritte mit der längsten Bearbeitungszeit (kritischer Pfad) bestimmt die Gesamtbearbeitungszeit.

    Die Performance-Dimension Bearbeitungszeit wird idealisiert durch folgende Größen für jeden einzelnen Anwendungsfallaufruf ermittelt:

    Die Bearbeitungszeiten für einen Anwendungsfall sind nicht für jeden Aufruf gleich. Zum einen können die ausführenden Produkte von Fall zu Fall unterschiedlich sein (z. B. verschiedene Karten), zum anderen wird die Antwortzeit jedes einzelnen Produkts variieren, oft abhängig von zufälligen Situationsparametern.

    So kommt es zu einer Verteilung von Bearbeitungszeiten. Im Modell der Bearbeitungszeiten wird diese Verteilung auf zwei statistische Größen reduziert:

    Beide Größen addieren sich für unabhängige Teilschritte unabhängig von der Verteilungsfunktion der Antwortzeiten pro Teilschritt (siehe [UnabhZufall]). Unter der Näherung einer Gaußverteilung der Antwortzeiten lässt sich die Varianz in ein p-Quantil übersetzt, dass sich selbst nicht für einzelne Teilschritte addiert.

    Die Zerlegung einer Funktion in Teilfunktionen und die Nutzung der Modellgrößen und illustriert Abbildung 1.

    Abbildung 1: Beispiel für Zerlegung einer Funktion und die Modell-Bearbeitungszeitgrößen

    Bei Messungen korrespondiert der Erwartungswert des Modells mit dem arithmetischen Mittelwert der Bearbeitungszeiten1 über eine Gesamtheit von N Einzelmessungen. Er berechnet sich als Summe der Bearbeitungszeiten geteilt durch die Anzahl N der Einzelmessungen.

    1) Mittelwert steht hier ausschließlich für den arithmetischen Mittelwert.

    Als Performancevorgaben hinsichtlich Bearbeitungszeit werden für eine definierte Umgebung zwei Schranken vorgegeben:

    2) Vereinfachend in der Bezeichnung werden Erwartungswert des Modells und arithmetischer Mittelwert der Messungen gleichermaßen mit bezeichnet.

    Für eine Gesamtheit von 100 Einzelmessungen darf der Mittelwert der Bearbeitungszeiten nicht größer als die zugehörige Schranke sein und die 99 niedrigsten Bearbeitungszeiten dürfen nicht größer als die Quantilschranke sein.

    Für die Produkttypen der zentralen Zone der TI-Plattform müssen Bearbeitungszeitvorgaben unter Last erfüllt werden. Da dabei nicht immer ein Stichprobenumfang von genau 100 Einzelmessungen pro Operation realisiert werden kann, ist es notwendig das gemessene 99%-Quantil für einen allgemeinen Stichprobenumfang der Anzahl n zu definieren.

    Quantil-Definition

    = Bearbeitungszeit der m-ten Bearbeitungszeit, wobei diese nach aufsteigendem Wert geordnet sind. Dabei ist m[n] = (n – n mod 100) * 0,99 + n mod 100.

    Beispiele: m[100] = (100 – 0) * 0,99 + 0 = 99 und m[17] = (17 – 17) * 0,99 + 17 = 17

    Inhaltliche Begründung: Ein Ausreißer wird immer nur für volle 100 Aufrufe zugelassen.

    2.2 Last

    Jede Funktion wird von ihren Nutzern im Betrieb mit einer gewissen Häufigkeit aufgerufen. Die dem Aufruf folgende Verarbeitung innerhalb einer Produktinstanz erzeugt für diese eine Arbeitslast.

    Es stellt sich die Frage, wie viele Anfragen parallel von einer Produktinstanz bearbeitet werden müssen. Um dies zu klären, wird zunächst gezeigt, welche Bedeutung der Mittelungszeitraum hat. Auf dieser Grundlage wird dann die Modellierung der Aufrufrate skizziert.

    Die Performance-Dimension Last wird idealisiert durch eine Liste der einzelnen Aufrufzeitpunkte repräsentiert .

    Abbildung 2 skizziert die Aufrufzeitpunkte für eine Funktion beispielhaft.

    Abbildung 2: Beispiel für gemessene Aufrufe, die zu Aufrufzeitpunkten erfolgen

    Eine solche exakte Verteilungsfunktion der Aufrufe kann gemittelt werden, indem man zu jedem Zeitpunkt über einen gewissen Zeitraum in der Vergangenheit die Aufrufe zählt und die Anzahl durch den Mittelungszeitraum T teilt. Man erhält so eine Aufrufrate , die auch vom Zeitintervall T abhängt.

    Die Abbildung 3 skizziert die Aufrufrate zu der Situation aus Abbildung 2 und identifiziert die höchste Aufrufrate – die „Spitze“ – im Mittelungszeitraum.

    Abbildung 3: Beispiel einer über den Zeitraum T gemittelten Aufrufrate

    Entspricht der Mittelungszeitraum T der mittleren Antwortzeit, dann gibt eine Spitze die parallel zu bearbeitenden Aufrufe an.

    Ein kleinerer Mittelungszeitraum erhöht die Spitzenraten [1/sec] beliebig. Ein größerer Mittelungszeitraum nivelliert die für die Bearbeitung praktisch relevanten, tatsächlich parallel zu verarbeitenden Aufrufzahlen.

    Auf Grund dieser Überlegungen wird im Folgenden der Zeitraum T immer gleich der Schranke für den Bearbeitungszeitmittelwert gesetzt. Die Einheit der Aufrufrate kann davon unabhängig für beliebige Zeiteinheiten als [1/Zeiteinheit] angegeben werden, etwa mit [1/sec], [1/h] oder [1/ ].

    Modellierung der Aufrufrate

    Ziel einer modellhaften Betrachtung der Aufrufrate ist eine möglichst gute Schätzung für die Spitzen in der Aufrufrate . Ausgangspunkt ist die Anzahl der auf einen großen Zeitraum entfallenden Aufrufe, etwa pro T = 1 Jahr = 1y. Anzahl geteilt durch Zeitraum T ergibt die Aufrufrate . Diese Aufrufrate wird bis zu einer Spitzenlast (oder mehreren fallabhängigen Spitzenlasten) entwickelt (Abbildung 4).

    Abbildung 4: Entwicklung der Spitzenlast (oder mehreren fallabhängigen Spitzenlasten) aus einer Durchschnittslast pro Jahr.


    Die so bestimmte modellierte Spitzenrate hat folgende Bedeutung:




    Die Aufrufrate wird ausgehend von einem auf ein Jahr bezogenen Mengengerüst, unter Berücksichtigung aller verfügbaren Informationen über das Benutzerverhalten, auf eine (oder mehrere fallbezogene) Spitzenlasten entwickelt. Diese Spitzenlast beschreibt für den jeweiligen Spitzenlastzeitraum zufällig verteilte Anfragen. Der zeitliche Abstand der Anfragen ist exponentialverteilt und ihre Häufigkeit für ein Zeitintervall poisson-verteilt. Wird als Zeitintervall die erwartete Bearbeitungszeit gewählt, ist durch diese Poisson-Verteilung die Anzahl der parallel zu bearbeitenden Anfragen beschrieben.

    Lastbegriff

    Durch zwei Anforderungen wird gewährleistet, dass Aufrufe auch erwartungsgemäß bearbeitet werden:

    Für jeden Produkttyp der TI-Plattform wird gefordert, dass die an seinen Außenschnittstellen angebotenen Operationen, bei der maximal erwarteten Aufrufrate für diese Schnittstelle funktional korrekt bearbeitet werden. Beispiel für eine solche reine Durchsatzanforderung ist die Anforderung an die Störungsampel.

    Sollte es vorkommen, dass die gemäß Spitzenlast maximal erwartete Aufrufrate überschritten wird, muss sich die TI-Plattform stabil verhalten, was durch die Anforderung [GS-A_4145] für Produkttypen der zentralen Zone der TI-Plattform sichergestellt wird.

    Im Folgenden verwendete Lastbegriffe:

    2.3 Verfügbarkeit

    Folgende Begriffe werden definiert:

    Abweichend gilt für die Fachdienste VSDM (UFS, VSDD, CMS), dass ein Ausfall vorliegt, wenn der Fachdienst nicht zur Verfügung steht. Der Ausfall der definierten funktionalen Eigenschaften der Fachdienste VSDM wird durch das Service Monitoring ermittelt. 

    Die Performance-Dimension Verfügbarkeit wird über die Gesamtzeit und die Dauer der konkreten  Ausfälle berechnet. Dabei ist ein konkretes Zeitintervall durch einen konkreten Startzeitpunkt und einen konkreten Endzeitpunkt beschrieben (z. B.: 17.08.2015 16:35:00 bis 17.08.2015 16:40:00). Wenn nicht ein gesamter Dienst ausgefallen ist, muss zusätzlich noch erfasst werden, auf welche Schnittstellenoperationen oder Verbindungen im Falle des zentralen Netzes sich der Ausfall bezieht. Da Ausfälle grundsätzlich selten erfolgen dürfen, besteht kein Bedarf diese Messdaten für ein etwaiges Reporting vor der Lieferung zu aggregieren.

    Aggregierte Sicht auf Verfügbarkeiten

    Um die Verfügbarkeit der TI für einen Anwendungsfall zu bestimmen, muss die Verfügbarkeit aller für die Bearbeitung einer Anfrage notwendigen Produkttypen berücksichtigt werden. Genauer müssen die konkreten Zeitintervalle aller Ausfälle berücksichtigt werden.

    Zwei Extremfälle können auftreten:

    Der erste Fall wird im Folgenden vereinfachend für die Modellierung der Verfügbarkeit angenommen. Der zweite Fall muss vom Betrieb berücksichtigt werden, weil hier durch Koordination von Ausfallzeitintervallen bei fixer Verfügbarkeit von Einzelkomponenten die Ende-zu-Ende-Verfügbarkeit für Anwendungsfälle gesteigert werden kann.

    Caching

    Der positive Effekt des Cachings auf die Verfügbarkeit von Anwendungsfällen ist tageszeitabhängig. Beim Stellen von Verfügbarkeitsanforderungen an die Produkttypen wird der Caching-Effekt daher nicht berücksichtigt.

    Toleranzschranken für längste Ausfalldauer und Verfügbarkeit

    Toleranzschranken für die Verfügbarkeit in Prozent und die längste Ausfalldauer bilden die zu definierenden Verfügbarkeitsanforderungen. Mit der Angabe eines Bezugszeitraumes (Monat oder Jahr) kann die Vorgabe einer Toleranzschranke für die längste Ausfalldauer entfallen, wenn die tolerierte Gesamtausfallzeit im Bezugszeitraum unterhalb der Toleranzschranke für die längste Ausfalldauer liegt.

    2.4 Einsatz der Performance-Kenngrößen

    Die Performance-Betrachtung dient dem Ziel, die benötigte und erwartete Leistung in Bezug auf die Performance-Dimensionen „Bearbeitungszeit, Last und Verfügbarkeit “ für die Anwendungsfälle dauerhaft im Betrieb zur Verfügung zu stellen.

    Um dies zu erreichen, werden zum einen Blattanforderungen für das Bearbeitungszeitverhalten von Operationen an den Außenschnittstellen der Produkttypen gestellt. Dabei wird auch festgelegt unter welcher Last diese Vorgaben zu erfüllen sind. Diese sind zulassungsrelevant. Zum anderen werden Performance-Daten im Betrieb erfasst, die eine Rückkopplung auf verschiedenen Ebenen erlauben:

    GS-A_4146-01 - Performance – Performance-Daten erfassen

    Die Produkttypen der zentralen Zone der TI-Plattform und die Komponente AdV-Server der KTR-AdV  MÜSSEN in einem konfigurierbaren Zeitintervall Performance-Daten erfassen. Voreingestellt für das Zeitintervall sind 5 Minuten.

    Die aufzunehmenden Performance-Kenngrößen definiert Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr].
    [<=]

    GS-A_4147-02 - Performance – Störungsampel – Performance-Daten

    Die Produkttypen der zentralen Zone der TI-Plattform MÜSSEN die Performance-Reporting-Daten jeweils im Zeitintervall der Erfassung von Performance-Reporting-Daten an die Störungsampel senden.

    Die aufzunehmenden Performance-Kenngrößen definiert Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr]. [<=]

    GS-A_4148-01 - Performance – Störungsampel – Ereignisnachricht bei Ausfall

    Die Produkttypen der zentralen Zone der TI-Plattform MÜSSEN den Start- und den Endzeitpunkt jedes Ausfalls als Ereignisnachricht an die Störungsampel senden. Die Dauer zwischen „Startzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ sowie die Dauer zwischen „Endzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ MUSS der Produkttyp unter 1 min halten, wobei die folgenden Definitionen gelten:


    [<=]

    Hinweise:

    A_14936 - Performance - Störungsampel - Ereignisnachricht bei Ausfall zentrale Dienste

    Die Produkttypen OCSP-Proxy, TSP-X.509 Komp., TSL-Dienst, Namensdienst, Störungsampel, KSR, SG-Bestandsnetze, Zeitdienst, zentrales Netz und Verzeichnisdienst MÜSSEN den Start- und den Endzeitpunkt jedes Ausfalls als Ereignisnachricht an die Störungsampel senden. Die Dauer zwischen „Startzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ sowie die Dauer zwischen „Endzeitpunkt eines Ausfalls“ und „Versendezeitpunkt“ MUSS der Produkttyp unter 1 min halten, wobei die folgenden Definitionen gelten:

    [<=]

    GS-A_4149-01 - Performance – Reporting-Daten in Performance-Report

    Die Produkttypen der zentralen Zone der TI-Plattform und die Komponenten AdV-Server der KTR-AdV MÜSSEN die Performance-Reporting-Daten ohne weitere Aggregation in den Performance-Report übernehmen.

    Die aufzunehmenden Performance-Kenngrößen definiert Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr].

    [<=]

    Performance-Reporting-Daten

    Die Performance-Reporting-Daten werden von den Anbietern an die gematik übermittelt, um eine Aussage über den aktuellen Zustand der TI zu ermöglichen.  Es wird produkttypübergreifend festgelegt, welche Performance-Reporting-Daten in jedem Erfassungsintervall erfasst werden müssen.

    Last:

    Bearbeitungszeit (jeweils pro Schnittstellenoperation)

    Verfügbarkeit (jeweils pro Schnittstellenoperation)

    Produkttypspezifisch sind die Operationen und gegebenenfalls weitere Parameter nach denen ein Aufriss der Bearbeitungszeiten erfolgt. Ein etwaiger weiterer Aufriss (etwa nach Verbindungen von Produkttyp zu Produkttyp beim zentralen Netz) erfolgt ebenfalls produkttypspezifisch.

    Relevanz für Service Level Agreements

    Service Level Agreements (SLA) bzgl. Performance-Vorgaben werden für alle Produkttypen der zentralen Zone der TI-Plattform vereinbart.

    Die Prozesse zum Service Level Management legen die Richtlinien zum Betrieb [gemRL_Betr_TI] fest. Sie beinhalten Anforderungen zum Service Level Reporting.

    Welche Performance-Kenngrößen in den Service Level Reports aufgenommen werden, legt die Spalte „Service Level Report“ in Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr] fest.

    Die konkreten Leistungsanforderungen pro Produkttyp stellt Kapitel 4 dar.

    Für die Auswertung der Bearbeitungszeiten wird geprüft, ob die Mittelwertschranke bezogen auf den Monatszeitraum eingehalten wird. Zur Überprüfung der 99%-Quantilvorgaben wird geprüft, ob die Anzahl der Antwortzeiten größer der vorgegebenen 99%-Quantilschranke kleiner gleich 1 % der Gesamtanfragen ist.

    Wenn nicht explizit angegeben, ist die maximale Ausfalldauer für SLAs als
    (1 – Verfügbarkeit) * 1 Monat anzusetzen.

    Sind die Verfügbarkeitsanforderungen pro Produkttyp definiert, so müssen sie durch jede von ihm angebotene Schnittstellenoperation für sich erfüllt werden. Die hierfür maßgeblichen Schnittstellenoperationen gibt Tabelle  "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr] vor. Ein Produkttyp erfüllt die Verfügbarkeitsanforderungen, wenn alle von ihm angebotenen Schnittstellenoperationen die Verfügbarkeitsanforderungen erfüllen.

    Die Lastangaben gelten, soweit nicht explizit abweichend angegeben, jeweils für alle Instanzen eines Produkttypen in Summe.

    2.5 Performance-Evaluierung auf der Basis von Rohdaten

    Die Rohdaten eines Produkttyps erfassen das Performanceverhalten von Diensten der TI. Diese Rohdaten beinhalten folgende Informationen:

    Aus den Rohdaten lassen sich die Performance-Kenngrößen (z.B. die Abbruchquote als Anteil der nicht erfolgreich verarbeiteten Aufrufe gemessen an der Anzahl der Aufrufe) für den Produkttyp ermitteln und auf deren Basis die Einhaltung der Service Level bestimmen. 

    Dazu erfassen Produkttypen die Rohdaten und stellen sie der Betriebsdatenerfassung in dem hier festgelegten Performance-Berichtsformat zur Verfügung.

    2.5.1 Rohdaten-Performance-Reporting (Rohdatenerfassung v.01)

    Anmerkung: Das Kapitel beschreibt die Rohdatenerfassung in der Version 1.0 und befindet sich aktuell in der strukturellen Überarbeitung. Inhaltliche Änderung werden sich lediglich in jener Form ergeben, dass die Produkte nach und nach zur Rohdatenerfassung in der Version 2.0 verpflichtet werden. Aktuell bestehende Zulassungen sind davon nicht betroffen. Das Update wird in Kürze eingearbeitet. 

    Im Folgenden ist das Berichtsformat in der Version v.01 beschrieben. Produkttypen, welche auf diese Version verpflichtet sind, werden im Laufe der Zeit auf die aktuellste Version angehoben. Neuzulassungen sind auf die Version v.01 nicht mehr möglich.

    A_17757-01 - Performance - Rohdaten-Performance-Lieferung - zu liefernde Dateien

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Berichten übermitteln, MÜSSEN jeweils zu jedem separat konfigurierbaren Berichtsintervall zwei Dateien senden:
    - einen "Rohdaten-Performance-Bericht" mit den zu liefernden Rohdaten [gemSpec_Perf#A_17755, A_17671, A_17668, A_19733-*]
    und
    - eine Datei zur "Selbstauskunft" gemäß [gemSpec_OM#GS-A_4543] im XML-Format [ProductInformation.xsd].

    Beide Dateien MÜSSEN separat an die Betriebsdatenerfassung gemäß gemSpec_SST_LD_BD an die Schnittstelle I_OpsData_Update gesandt werden. [<=]

    A_17755 - Performance - Rohdaten-Performance-Berichte - Name der Berichte

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN beim Dateinamen der Berichte folgende Namenskonvention umsetzen:

    <CI-ID>_<Start>_<Ende>_<Version der Datei>_<Dateityp>.<Endung>

    [<=]

    A_17671 - Performance - Rohdaten-Performance-Berichte - Format des Performance-Berichts

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN den Bericht aufbereitet als UTF-8-kodierte Textdatei ohne ByteOrderMark übermitteln. Jede der in diesem Kapitel in den jeweiligen Tabellen definierten Operationsaufrufe MUSS in einem Eintrag erfasst werden. Die Einträge MÜSSEN durch Zeilenumbruch (LF = 0x0A) getrennt werden.
    [<=]

    A_17668-07 - Performance - Rohdaten-Performance-Berichte - Format der Einträge des Rohdaten-Performance-Berichts

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN sämtliche Zeilen (Einträge) der Berichte in der folgenden Weise formatieren:

    INFO: start[$timestamp] time[$duration_in_ms] tag[$operation] size[$size_in_kb] message[$message],

    mit

    [<=]

    Ein Beispiel für zwei Einträge, der erste zu einem fehlerfreien Aufruf, der zweite zu einem Aufruf, der nicht fehlerfrei durchlaufen wurde:

    INFO: start[1000212390109] time[447] tag[UFS.GetUpdateFlags]
    INFO: start[1000212470109] time[2]   tag[UFS.GetUpdateFlags.failed]

    Hinweis:

    Unter einer fehlerhaften Operation wird verstanden, wenn die Operation z.B. selbst fehlerhaft abgebrochen wurde bzw. nicht oder zu spät beantwortet wurde. Eine Antwort auf ein nicht vorhandenes Datum (ICCSN, Seriennummer etc.) ist eine fehlerfreie Operation und nicht mit ".failed" zu kennzeichnen.

    A_17678 - Performance - Rohdaten-Performance-Berichte - Übermittlung

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN zur Übertragung der Reports die Schnittstelle I_OpsData_Update::fileUpload gemäß [gemSpec_SST_LD_BD#A_17733] verwenden.

    Die Übermittlung des Rohdaten-Performance-Berichts MUSS pro CI (Configuration Item) erfolgen. 
    [<=]

    Hinweis: Ein CI (Configuration Item) kann auch ein Knoten oder ein Standort sein.

    A_17679 - Performance - Rohdaten-Performance-Berichte - Berichtsintervall

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN das Berichtsintervall konfigurierbar gestalten.

    [<=]

    A_17756 - Performance - Rohdaten-Performance-Berichte - Korrektheit

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Berichte vollständig, zeitlich lückenlos (auch über Ausfälle hinweg) beginnend um 00:00:00 Uhr, überlappungsfrei, intervalltreu, syntaktisch und semantisch korrekt senden. "Intervalltreu" meint: Jeder Eintrag muss in dem Rohdaten-Performance-Bericht gesendet werden, in dessen Berichtsintervall sein Endezeitpunkt $timestamp + $duration_in_ms liegt.

    [<=]

    A_17758 - Performance - Rohdaten-Performance-Berichte - Frist für Nachlieferung

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, SOLLEN, falls im Ausnahmefall eine Lieferung nicht wie gefordert erfolgt, die Datei in der geforderten Qualität bis zum Ende des folgenden Werktages nachliefern.
    [<=]

    2.5.2 Rohdaten-Performance-Reporting (Rohdatenerfassung v.02)

    Anmerkung: Das Kapitel beschreibt die Rohdatenerfassung in der Version 2.0 und befindet sich aktuell in der strukturellen Überarbeitung. Die hier bereits aufgeführten Anforderungen werden dabei nicht verändert, sondern lediglich um Erläuterungen ergänzt. Das Update wird in Kürze eingearbeitet.

    Die Version v.02 der Rohdatenerfassung ersetzt die bisher zulassungsfähige Version v.01 und ist im Folgenden näher definiert. Neuzulassungen oder Änderungszulassungen sind nur auf Basis der Rohdatenerfassung v.02 möglich.

    Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02 gibt einen Überblick über die Produkttypen, welche bereits Rohdaten-Performance-Berichte in der Version v.02 übermitteln, bzw. sich aktuell in der Umstellung befinden.

    Tabelle 1 : Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02

    PDT Produkttyp
    PDT02 Trust Service Provider X.509 QES
    PDT03 Trust Service Provider X.509 nonQES - eGK
    PDT09 VPN-Zugangsdienst
    PDT36 Trust Service Provider X.509 nonQES - HBA
    PDT38 Trust Service Provider X.509 nonQES – SMC-B
    PDT50 E-Rezept-Fachdienst
    PDT52 Identity Provider Dienst
    PDT64 TI-Messenger Fachdienst
    PDT68 sektoraler Identity Provider

    A_22057 - Performance - Rohdaten - Verpflichtung des Anbieters (Rohdatenerfassung v.02)

    Der Anbieter von Produkten, deren zugeordnete Produkttypen ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MUSS die Erfassung, Aufbereitung und Übermittlung der Rohdaten bezüglich Umfang, Lieferintervalle und Format gemäß der allgemeinen und spezifischen Anforderungen (Rohdatenerfassung v.02) gewährleisten. [<=]

    A_22482 - Performance - Rohdaten - Erfassung von Rohdaten (Rohdatenerfassung v.02)

    Der Produkttyp MUSS Performance-Rohdaten gemäß der Vorgaben zum Rohdaten-Performance-Reporting v.02 erfassen. [<=]

    2.5.2.1 Umfang

    A_22002 - Performance - Rohdaten - Übermittlung (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN zur Übertragung der Berichte die Schnittstelle I_OpsData_Update::fileUpload gemäß [gemSpec_SST_LD_BD#A_17733] verwenden.

    Die Übermittlung des Rohdaten-Performance-Berichts MUSS pro Produktinstanz (CI ID - Configuration Item ID) nach Vorgabe der gematik erfolgen.  [<=]

    (Hinweis: Für weitere Informationen zum CI, siehe [gemRL_Betr_TI] Kapitel "Configuration Management".)

    A_22000 - Performance - Rohdaten - zu liefernde Dateien (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN folgende zwei Dateien in den jeweils individuell konfigurierbaren Berichtsintervallen senden:
    - einen "Rohdaten-Performance-Bericht" mit den zu liefernden Rohdaten
    und
    - eine Datei zur "Selbstauskunft" gemäß [gemSpec_OM#GS-A_4543] im XML-Format [ProductInformation.xsd].

    Dabei MÜSSEN beide Dateien separat an die Betriebsdatenerfassung gesendet werden. [<=]

    A_22429 - Performance - Rohdaten - Inhalt der Selbstauskunft (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, müssen bei der Erstellung der Selbstauskunft folgende inhaltliche Vorgaben berücksichtigen:

    [<=]

    A_22004 - Performance - Rohdaten - Korrektheit (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Berichte vollständig, zeitlich lückenlos (auch über Ausfälle hinweg), überlappungsfrei, intervalltreu, syntaktisch und semantisch korrekt senden.  [<=]

    "Intervalltreu" bedeutet hierbei: Jeder Eintrag muss in dem Rohdaten-Performance-Bericht gesendet werden, in dessen Berichtsintervall sein Endezeitpunkt $timestamp + $duration_in_ms liegt.

    A_22005 - Performance - Rohdaten - Frist für Nachlieferung (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN, falls im Ausnahmefall eine Lieferung nicht wie gefordert erfolgt, die Datei(en) in der geforderten Qualität bis zum Ende des folgenden Werktages (Mo-Fr ausgenommen bundeseinheitliche Feiertage) nachliefern. [<=]

    Die Nachlieferung hat dabei in der gleichen Art wie die Originallieferung zu erfolgen (keine Zusammenfassung mehrerer Rohdaten-Nachlieferungen). Bei mehreren Nachlieferungen sind die Einzellieferungen separat und zeitlich gestaffelt zwischen den Standardlieferungen zu tätigen (z.B. bei einem 5-Minuten-Intervall nach 2,5 Minuten EINE Nachlieferung und nach 5 Minuten dann die Standardlieferung).

    A_22003-01 - Performance - Rohdaten - Nachlieferung auf Anforderung (Rohdatenerfassung v.02)

    Anbieter, deren Produkttypen ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN auf Anforderung des Gesamtverantwortlichen TI eine erneute Lieferung/Nachlieferung der Rohdaten-Berichte bis zum 5. Werktag (Mo-Fr, ausgenommen bundeseinheitliche Feiertage) des auf dem Berichtszeitraum folgenden Monats ermöglichen. [<=]

    Die vorgeschriebenen Aufbewahrungspflichten bleiben hiervon unberührt. Umfang und Details zur Nachlieferung bzgl. Nachlieferungszeitpunkt und Zusammenfassung sind mit dem Gesamtverantwortlichen TI abzustimmen.

    A_22996 - Performance - Rohdaten - Zeitpunkte der Übermittlungen (Rohdatenerfassung v.02)

    Der Anbieter, der zur Rohdatenlieferung verpflichtet ist, MUSS jede Lieferung der Rohdaten unverzüglich - spätestens innerhalb der 10 auf das Berichtsintervall folgenden Minuten - beginnen.
    [<=]

    2.5.2.2 Lieferintervalle

    A_21976 - Performance - Rohdaten - Konfigurierbarkeit der Lieferintervalle (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Lieferintervalle der Berichtsdateien flexibel zwischen 1 Minute und 24 Stunden (1440 Minuten) mit einer Taktung von 1 Minute konfigurieren können, ohne ein Produktupdate durchführen zu müssen. [<=]

    A_22047 - Performance - Rohdaten - Änderung der Konfiguration der Lieferintervalle (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN eine Anpassung der Lieferintervalle der Berichtsdateien auf Aufforderung des Gesamtverantwortlichen TI ermöglichen. [<=]

    Die Anpassung der Lieferintervalle ist im Rahmen des TI-ITSM durch das Changemanagement zu prozessieren.

    A_22620 - Rohdaten - Umsetzungszeit für Änderung der Lieferintervalle

    Der Anbieter, dessen Produkt zur Umsetzung der Rohdatenerfassung v.02 verpflichtet ist, MUSS die Änderung der Konfiguration der Lieferintervalle (gemäß A_22047) innerhalb von 5 Werktagen (Mo - Fr, ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]

    A_21978 - Performance - Rohdaten - Trennung der Lieferintervalle (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN eine voneinander getrennte Anpassung der Lieferintervalle für die Lieferungen von Rohdaten-Performance-Berichten, Selbstauskünften und ggf. weiteren Lieferungen (z.B. Bestandsdatenlieferung) ermöglichen. [<=]

    A_21975 - Performance - Rohdaten - Default-Werte für Lieferintervalle (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN - sofern nicht explizit spezifiziert - folgende Lieferintervalle als Standardeinstellung voreinstellen:

    [<=]

    A_21979 - Performance - Rohdaten - Bezug der Lieferverpflichtung (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN sich bei der Lieferung der Berichtsdateien ausschließlich am Lieferintervall orientieren (NICHT z.B. an der Datenmenge). [<=]

    A_21980 - Performance - Rohdaten - Leerlieferung (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN die Lieferung der Berichtsdateien gemäß des konfigurierten Lieferintervalls leisten, auch wenn im dazugehörigen Berichtsintervall keine Operationsausführung stattgefunden hat. In diesem Fall ist der Rohdaten-Performance-Bericht mit dem Inhalt 'leer' (4 Zeichen) zu übertragen. Für die Selbstauskunft ergibt sich daraus keine Besonderheit, sodass diese wie definiert zu übertragen ist. [<=]

    2.5.2.3 Format

    A_22001-01 - Performance - Rohdaten - Name der Berichte (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN beim Dateinamen der Berichte folgende Namenskonvention umsetzen:

    <CI-ID>_<Start>_<Ende>_<Dateityp>.<Endung>

    [<=]

    A_21981-02 - Performance - Rohdaten - Format des Rohdaten-Performance-Berichtes (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN bei der Erstellung folgende Konventionen erfüllen:
    Diese Produkttypen:

    timestamp; duration_in_ms; operation; status; message mit folgender Bedeutung verwenden: 

    [<=]

    A_22500-01 - Performance - Rohdaten - Status-Block (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN im Status-Block entweder einen HTTP-Statuscode gemäß Tab_gemSpec_Perf_Standard-Statuscodes oder gemäß produkttypspezifischer Definition übermitteln.

    Tabelle 2: Tab_gemSpec_Perf_Standard-Statuscodes 

    HTTP-Statuscodes
    Name der Statuscodegruppe Beschreibung
    1xx INFORMATIONAL Der Server hat die Anfrage erhalten und befindet sich in der Bearbeitung.
    2xx
    SUCCESSFUL
    Die Operation wurde erfolgreich durchgeführt.
    3xx REDIRECTION Der Client muss zusätzliche Maßnahmen ergreifen, um die Anfrage abzuschließen.
    4xx
    CLIENT_ERROR
    Ein Client-seitiger Fehler verhindert die erfolgreiche Durchführung der Operation.
    5xx
    SERVER_ERROR
    Ein Server-seitiger Fehler verhindert die erfolgreiche Durchführung der Operation.
    [<=]

    Hinweis: Es sind die konkreten HTTP-Statuscodes zu verwenden und die "xx" entsprechend zu ersetzen.

    A_21982-01 - Performance - Rohdaten - Message-Block (Rohdatenerfassung v.02)

    Produkttypen, die ihre Performance-Messwerte in Rohdaten-Performance-Berichten übermitteln, MÜSSEN bei der Erstellung des Message-Blocks (message-Feld im CSV-formatierten Rohdaten-Performance-Bericht) das JSON-Format (gemäß [RFC 8259] oder [ECMA-404]) für den gesamten Message-Block verwenden. [<=]

    A_22513-01 - Performance - Rohdaten - Message-Block im Fehlerfall (Rohdatenerfassung v.02)

    Der Produkttyp MUSS das betroffene Key-Value-Paar mit <<"key":null>> übermitteln, wenn - im Fehlerfall oder aus einem anderen Grund - die für die Erstellung des Message-Blocks (message-Feld im CSV-formatierten Rohdaten-Performance-Bericht) notwendigen Informationen nicht vorliegen.
    (anstelle von key ist der entsprechende Key-Wert des Key-Value-Paares einzutragen; << und >> dienen nur der Abgrenzung)
    [<=]

    Zwei beispielhafte Einträge eines Beispielproduktes und einer dazugehörigen Beispieloperation:

    I:   1000212390109;447;Beispielprodukt.Beispieloperation;200;{"ID":12}

    II:  1000212470109;12;Beispielprodukt.Beispieloperation;40001;{"ID":12,"Antwort":"gesperrt"}

    3 Produkttypspezifische Vorgaben

    Die produkttypspezifischen Vorgaben dieses Kapitels ergänzen die allgemeinen Anforderungen der Rohdatenerfassung für jeden Produkttypen zusammengefasst und übersichtlich.

    Anmerkung: Das Kapitel befindet sich derzeit im Aufbau und wird im Laufe der Zeit die Festlegungen der Folgekapitel 4 und 5 zusammenfassen. Dies geschieht stets produkttypbezogen, sodass es in der Übergangszeit Produkttypen geben kann, welche bereits in die neue produkttyporientierte Dokumentenstruktur überführt wurden, während sich andere noch in der thematisch-fokussierten Dokumentenstruktur wiederfinden.

    3.1 IDP-Dienste

    3.1.1 Leistungsanforderungen IDP-Dienste

    3.1.1.1 Lastmodell IDP-Dienste

    Die Tokenbasierte Authentisierung umfasst folgende performance-relevanten Operationen:

    [Weiteres im Folgekapitel "Performancevorgaben IDP-Dienste" enthalten]

    3.1.1.2 Bearbeitungszeiten IDP-Dienste

    Für die Tokenbasierte Authentisierung müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_Bearbeitungszeitvorgaben Tokenbasierte Authentisierung je Anwendungsfall" angegebenen Mittelwertschranken sein.

    Tabelle 3: Tab_Bearbeitungszeitvorgaben Tokenbasierte Authentisierung je Anwendungsfall

    Anwendungsfall
    Datenmenge
    [KB]
    Mittelwert
    [sec]
    I_IDP_Auth_Active_Client::
    issue_Identity_Assertion
    5
    2,5
    I_IDP_Auth_Active_Client::
    renew_Identity_Assertion
    20
    2,5
    I_IDP_Auth_Active_Client::
    cancel_Identity_Assertion
    20
    0,5
    I_IDP_Auth_Passive _Client::
    signin
    2
    3,5
    I_IDP_Auth_Passive_Client::
    signout
    <1
    0,5
    I_Local_IDP_Service::
    sign_Token
    5
    2,5

    A_22532 - Überlastabwehr des Produktes

    Der Produkttyp KANN bei einer erhöhten Anfragelast von mehr als 20 Authorization-Requests innerhalb von 5 Minuten pro "client_id" und anfragender IP-Adresse weitere Anfragen dieser Quelle mit dem HTTP-Statuscode "429 - Too Many Requests" ablehnen. [<=]

    3.1.1.3 Performancevorgaben IDP-Dienste

    A_22227-01 - Performance – IDP-Dienst – Bearbeitungszeit unter Last

    Der Produkttyp IDP-Dienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_IDP-Dienst erfüllen.

    Es wird davon ausgegangen, dass der IDP-Dienst eingeschwungen ist und z.B. Lokalisierungsanfragen lokal zwischengespeichert sind sowie Verbindungen nicht neu ausgehandelt werden.
    Im Fall der Authorization Requests zählt die Zeit von Anfrage des Authenticator (Challenge) bis zum Eintreffen der Antwort (Response) nicht zur Bearbeitungszeit. Die Dauer für die OCSP-Anfrage ist jedoch berücksichtigt.

    Für die Zulassung ist je Anwendungsfall der Nachweis bei einer Last von 100 Anfragen pro Sekunde zu erbringen.


    Tabelle 4: Tab_gemSpec_Perf_IDP-Dienst: Bearbeitungszeitvorgaben

    ID
    Anwendungsfälle
    Lastvorgaben
    Bearbeitungszeitvorgaben
    Spitzenlast
    [1/sec]
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    IDP.UC_1
    IDP.UC_3
    IDP.UC_11

    Authorization Requests
    450
    500
    664
    IDP.UC_5
    IDP.UC_6
    IDP.UC_7
    IDP.UC_8
    IDP.UC_9
    IDP.UC_10
    IDP.UC_12



    Processing of Client-Response


    450


    1750


    2250
    IDP.UC_2
    IDP.UC_4
    Token Requests 450 500 664
    [<=]

    A_22226 - Performance – Sektoraler Identity Provider – Bearbeitungszeit unter Last

    Der Anbieter eines sektoralen Identity Provider MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Sek_IDP erfüllen.
    Es wird davon ausgegangen, dass der sektorale Identity Provider eingeschwungen ist und z.B. Lokalisierungsanfragen lokal zwischengespeichert sind, sowie Verbindungen nicht neu ausgehandelt werden.
    MA ist der Marktanteil des Anbieters gemäß [A_22225].
    Im Fall der Authorization Requests zählt die Zeit von Anfrage des Authenticator-Moduls bis zum Eintreffen der Antwort nicht zur Bearbeitungszeit.

    Tabelle 5: Tab_gemSpec_Perf_sek_IDP: Bearbeitungszeitvorgaben

    ID
    Anwendungsfälle
    Lastvorgaben
    Bearbeitungszeitvorgaben
    Spitzenlast
    [1/sec]
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    IDP.UC_20
    Processing of Authorization Request (third-party-based authentication) 10 + (450 x MA)
    1500
    1964
    IDP.UC_21
    Token Request (third-party-based authentication) 10 + (450 x MA)
    500
    664

    [<=]

    Hinweis:

    Die Duration für IDP.UC_20 beginnt mit der Annahme des Authorization Request am Authorization-Endpunkt und endet mit der Herausgabe des Authorization_Code.
    Die Duration für  IDP.UC_21 beginnt mit der Annahme des Token Request am Token-Endpunkt und endet mit der Herausgabe des Token.

    A_22833 - Performance – Sektoraler Identity Provider in der Föderation – Bearbeitungszeiten unter Last

    Der Anbieter des sektoralen Identity Provider MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_sektoraler_IDP erfüllen.
    Es wird davon ausgegangen, dass der sektorale Identity Provider eingeschwungen ist und z. B. Lokalisierungsanfragen lokal zwischengespeichert sind, sowie Verbindungen nicht neu ausgehandelt werden.
    MA ist der Marktanteil des Anbieters gemäß [A_22225].
    Im Fall der Authorization Requests zählt die Zeit von Anfrage des Authenticator-Moduls bis zum Eintreffen der Antwort nicht zur Bearbeitungszeit.

    Tabelle 6: Tab_gemSpec_Perf_sektoraler_IDP: Bearbeitungszeitvorgaben

    ID
    Anwendungsfälle Lastvorgaben
    Bearbeitungszeitvorgaben
    Spitzenlast
    [1/sec]
    Maximalwert
    [msec]


    IDP.UC_30 Processing of Pushed Authorization Requests  10 + (450 x MA) 800
    IDP.UC_31
    Processing of Authorization Requests
    (alle Authentisierungsverfahren)
    10 + (450 x MA) 2000
    IDP.UC_32,
    IDP.UC_33
    IDP.UC_34
    Response of Authorization Requests (mit online Ausweisfunktion)
    Response of Authorization Requests (mit eGK und PIN)
    Response of Authorization Requests (alternatives Authentisierungsverfahren)
    10 + (450 x MA) 100
    IDP.UC_39 Token Requests 10 + (450 x MA) 800

    Hinweise: 
    Die Duration für IDP.UC_30 beginnt mit der Annahme des Pushed Authorization Request (PAR) vom Authorization-Server des Fachdienstes und endet mit der Übermittlung der "URI-PAR" zum Authorization-Server des Fachdienstes. Zeiten zwischen der optionalen Anfrage "Get Entity Statement RP" des sektoralen IDP an den Fachdienst und der Antwort "Entity Statement" sowie der optionalen Anfrage "Fetch Entity Statement RP" des sektoralen IDP an den Federation Master und Antwort "Entity Statement" sind in der Berechnung für den IDP.UC_30 herauszurechnen.

    Die Duration für IDP.UC_31 beginnt mit der Annahme des Authorization Request (URI-PAR) vom Authenticator-Modul und enden mit dem Absenden der Anfrage zur Authentifizierung.
    Die Duration für IDP.UC_32 - IDP.UC_34 beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung  und endet mit der Übermittlung der "Redirect to redirect url, AUTH_CODE" zum Authenticator-Modul. 
    Die Duration für IDP.UC_35  beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung  und endet mit der Übermittlung eines Fehlercodes an die Betriebsdatenerfassung.
    Die Duration für IDP.UC_39 beginnt mit der Annahme des AUTH_CODE vom Authorization-Server des Fachdienstes und endet mit der Übermittlung des ID_TOKEN (ACCESS_TOKEN) zum Authorization-Server  des Fachdienstes.

    [<=]

    A_20243 - Performance - IdP-Dienst - Robustheit gegenüber Lastspitzen

    Der IdP-Dienst MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_IdP-Dienst: Bearbeitungszeitvorgaben" verfügbar bleiben. [<=]

    Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der Dienst vorübergehend abweisen. Dabei müssen die definierten Spitzenlasten weiterhin innerhalb der Performancevorgaben verarbeitet werden. Vom System angenommene Anfragen müssen weiterhin innerhalb der Performancevorgaben verarbeitet werden. Der Betreiber des Fachdienstes hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.

    A_20153 - Performance - IdP-Dienst - Anzahl paralleler Sessions - TI

    Der Produkttyp IdP-Dienst MUSS mindestens 95.000 gleichzeitige Sessions für Leistungserbringer unterstützen.
    [<=]

    A_20154 - Performance - IdP-Dienst - Anzahl paralleler Sessions - Internet

    Der Produkttyp IdP-Dienst MUSS mindestens 2.400.000 gleichzeitige Sessions für Versicherte unterstützen.
    [<=]

    A_22225 - Definition Marktanteil (MA) des Anbieters einer Anwendung oder eines Dienstes

    Der Anbieter MUSS entsprechend seines Marktanteils (MA) Performancevorgaben und Service Level erfüllen. Der Marktanteil ist der numerische Wert zwischen 1,00 und 0,01 [ohne Einheit, zwei Nachkommastellen, aufgerundet], der den Anteil der eigenen Kunden des Anbieters im Verhältnis zur Gesamtnutzerzahl repräsentiert. Die Gesamtnutzerzahl ist die Zahl aller Versicherten (privat + gesetzlich) oder die Anzahl aller Leistungserbringer und Leistungserbringerinstitutionen, die diese Anwendung nutzen. [<=]

    Hinweis: Die potentiellen Gesamtnutzerzahlen je Sektor können bei den Standesorganisationen oder der gematik erfragt werden.

    A_22228 - Performance - Sektoraler Identity Provider - Anzahl paralleler Sessions - Internet

    Der Anbieter eines sektoralen Identity Provider MUSS mindestens 25.000 x MA gleichzeitige Sessions für Versicherte unterstützen. MA ist der Marktanteil des Anbieters gemäß [A_22225].
    [<=]

    A_20244 - Performance - IdP-Dienst - Skalierung

    Der Betreiber des IdP-Dienst MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird.
    [<=]

    Im Zuge des Zulassungsverfahrens hat der Betreiber des IdP-Dienst der gematik gegenüber nachvollziehbar darzustellen, welche technischen Skalierungsmaßnahmen anhand welcher messbarer Parameter er für den Produktivbetrieb plant durchzuführen. Die Skalierungsmaßnahmen können dabei unterschiedliche Ausprägungen und Dimensionen umfassen. Beispielsweise eine automatisierte Ressourcenzuteilung oder eine Anpassung oder Änderung unterschiedlicher technischer Komponenten, die zu einer Produktänderung im Sinne der [gemSpec_OM] führt. Die Darstellung muss Verifikationsbeschreibungen enthalten, mit denen der Erfolg der Maßnahmen ermittelt werden kann.

    A_19730-01 - Georedundanz des IdP-Dienstes

    Der Anbieter des IdP-Dienstes MUSS diesen Dienst an mindestens zwei Standorten, die mindestens 50km jeweils voneinander entfernt sind, betreiben. Jeder Standort MUSS dabei die Performancevorgaben allein erfüllen.
    [<=]

    A_19718-01 - Performance – IdP-Dienst – Verfügbarkeit

    Der Produkttyp IdP-Dienst MUSS zur Hauptzeit eine Verfügbarkeit von 99,99 % und zur Nebenzeit eine Verfügbarkeit von 99,97 % haben.
    Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.
    Hauptzeit ist Montag bis Sonntag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
    [<=]

    A_22357-03 - Verfügbarkeit sektoraler IDP

    Der Anbieter des sektoralen IDP MUSS sein Produkttyp so betreiben, dass es zur Hauptzeit mindestens eine Verfügbarkeit von 99,90 % und zur Nebenzeit eine Verfügbarkeit von 99,00 % hat.
    Genehmigte Wartungsfenster dürfen nur in der Nebenzeit liegen und werden nicht als Ausfallzeit gewertet.
    Hauptzeit ist Montag bis Sonntag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
    [<=]

    3.1.2 Rohdaten-Performance-Reporting Spezifika IDP-Dienste

    In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.

    3.1.2.1 Spezifika Umfang IDP-Dienste

    A_22048-01 - Performance - Rohdaten - Übermittlung bei dislozierten CIs (Rohdatenerfassung v.02)

    Der Anbieter KANN die Übermittlung der Rohdaten-Performance-Berichte in Absprache mit dem Gesamtverantwortlichen TI je Standort vollziehen, wobei diese Standorte dann eindeutig identifizierbar sein müssen, sofern das Configuration Item (CI) über mehrere Standorte verteilt ist. [<=]

    3.1.2.2 Spezifika Format IDP-Dienste

    A_22012-02 - Performance - Rohdaten - Spezifika IDP - Duration (Rohdatenerfassung v.02)

    Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die konkretisierenden Hinweise unter der Tabelle Tab_gemSpec_Perf_Berichtsformat_IDP bzw. Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP berücksichtigen. Die Messung zur Ermittlung der Dauer beginnt mit der Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht an die annehmende Schnittstelle des Empfängers. Registriert wird dabei der Zeitpunkt aus dem Header. [<=]

    A_22013-03 - Performance - Rohdaten - Spezifika IDP - Operation (Rohdatenerfassung v.02)

    Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe aus der Tabelle Tab_gemSpec_Perf_Berichtsformat_IDP in der Spalte "$IDP-Operation" berücksichtigen.

    Tabelle 7: Tab_gemSpec_Perf_Berichtsformat_IDP

    $IDP-Operation
    Produkttyp Operation Schnittstelle zu Endpunkt Anwendungsfälle
    IDP.UC_1
    IDP-Dienst Processing of Authorization Requests
    TI GET/auth Authorization Requests (TI)
    IDP.UC_2 IDP-Dienst Token Requests TI POST/Token Token Request (TI)
    IDP.UC_3 IDP-Dienst Processing of Authorization Requests (smartcard based) Internet GET/auth Authorization Requests (Internet) 
    IDP.UC_4 IDP-Dienst Token Request Internet POST/Token Token Request (Internet)
    IDP.UC_5
    IDP-Dienst
    Processing of Client-Response (pairing-based authentication)
    TI
    POST/auth Processing of Client-Response (TI)
    IDP.UC_6 *
    IDP-Dienst
    Processing of Client-Response (SSO_TOKEN)
    TI
    POST/auth/
    sso_response
    Processing of Client-Response (TI)
    IDP.UC_7 *
    IDP-Dienst
    Processing of Client-Response (Card-based authentication)
    TI
    POST/alternative Processing of Client-Response (TI)
    IDP.UC_8
    IDP-Dienst
    Processing of Client-Response (pairing-based authentication)
    Internet
    POST/auth Processing of Client-Response (Internet)
    IDP.UC_9
    IDP-Dienst
    Processing of Client-Response (SSO_TOKEN)
    Internet
    POST/auth/sso_response Processing of Client-Response (Internet)
    IDP.UC_10
    IDP-Dienst
    Processing of Client-Response (Card-based authentication)
    Internet
    POST/alternative Processing of Client-Response (Internet)
    IDP.UC_11 ** IDP-Dienst Processing of Authorization Requests (third-party-based) Internet GET/extauth Authorization Requests (Internet) 
    IDP.UC_12 IDP-Dienst Processing of Client-Response (third-party-based) Internet POST/extauth Processing of Client-Response (Internet)
    Hinweise
    Die Duration für IDP.UC_1 und IDP.UC_3 beginnt mit der Annahme des Authorization Request und endet mit der Produktion der signierten Challenge. 
    Die Duration für IDP.UC_5 bis IDP.UC_10 beginnt mit der Annahme der signierten Authentication_Data-Struktur am Authorization-Endpunkt und endet mit der Rückgabe der produzierten Authorization_Codes und SSO_TOKEN an das Authenticator-Modul.  
    Die Duration für IDP.UC_11 beginnt mit der Annahme des Authorization Request und endet mit der Redirect-Antwort zum Authenticator Modul.

    Anmerkungen:
    * Diese Use Cases wurden im Sinne der Vollständigkeit definiert. In der Praxis wird aber weder der SSO Flow noch die Alternative Authentisierung in der TI genutzt
    ** Neu zu definierende Use Cases im Kontext des Fasttrack CRs CR_0020 [<=]

    A_22944 - Performance - Rohdaten - Spezifika föderierter IDP - Message (Rohdatenerfassung v.02)

    Der Produkttyp MUSS - bei Rohdaten-Performance-Berichten folgende Parameter im JSON-Format übermitteln:
           {"cv": "$client_version"}

    Für "$client_version" ist die Produktversion zum korrespondierenden Authenticator-Modul zu verwenden.

    [<=]

    A_22015-01 - Performance - Rohdaten - Spezifika IDP - Status (Rohdatenerfassung v.02)

    Wenn bei der Durchführung der Operation/des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp IDP-Dienst - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_IdP-Dienst festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich, MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.

    Tabelle 8: Tab_gemSpec_Perf_Fehlercodes_IdP-Dienst

    Statuscode
    Definition
    Beschreibung
    79001
    OCSP_ERROR_NO_RESPONSE
    Keine Antwort des OCSP oder Timeout
    79879
    OCSP_ERROR_WRONG_SIGNATURE
    Falsche oder fehlende Signatur in der OCSP-Antwort
    79875
    OCSP_ERROR_WRONG_DATA
    Format der OCSP-Anfrage fehlerhaft
    79881
    OCSP_ERROR_INVALID_RESPONSE
    Antwort des OCSP fehlerhaft
    79873
    OCSP_CERT_MISSING
    OCSP-Zertifikat nicht in TSL enthalten
    79101 SEK_IDP_ERROR_NO_RESPONSE Keine Antwort des sektoralen IDP oder Timeout
    79102 SEK_IDP_ERROR_INVALID_RESPONSE Antwort des sektoralen IDP fehlerhaft
    79105 SEK_IDP_ERROR_NOT_ALLOWED_USER Useragent/Version/ClientID nicht erlaubt
    79000
    IDP_ERROR
    alle internen Fehler des IDP
    [<=]

    A_22826 - Performance - Rohdaten - Spezifika sektoraler IDP - Status (Rohdatenerfassung v.02)

    Wenn bei der Durchführung der Operation/des Use Case ein Fehler aufgetreten ist, MUSS der Produkttyp sektoraler IDP bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_sektoraler_IdP festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich, MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.

    Tabelle 9: Tab_gemSpec_Perf_Fehlercodes_sektoraler_IDP

    Statuscode
    Definition
    Beschreibung
    79000
    IDP_ERROR
    alle internen Fehler des sektoralen IDP
    79105 SEK_IDP_ERROR_NOT_ALLOWED_USER Useragent/Version/ClientID-Kombination nicht erlaubt
    79106 SEK_IDP_AS_nPA_TIME_OUT Abbruch der Anfrage nach time-out (online Ausweisfunktion)
    79107 SEK_IDP_AS_nPA_USER_FAILURE Alle Fehler der third party online Ausweisfunktion
    79108 SEK_IDP_AS_eGK_TIME_OUT Abbruch der Anfrage nach time-out (eGK)
    79109 SEK_IDP_AS_eGK_USER_FAILURE Alle Fehler der third party eGK
    79110 SEK_IDP_AS_native_TIME_OUT Abbruch der Anfrage nach time-out
    79111 SEK_IDP_AS_native_USER_FAILURE Alle Fehler der third party 
    [<=]

    A_22825 - Performance - Rohdaten - Spezifika - Operation (Rohdatenerfassung v.02)

    Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe aus der Tabelle Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP in der Spalte "$IDP-Operation" berücksichtigen.

    Tabelle 10: Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP

    $IDP-Operation
    Produkttyp Operation Schnittstelle zu
    IDP.UC_30
    sektoraler Identity Provider  Processing of Pushed Authorization Requests
    Internet
    IDP.UC_31 sektoraler Identity Provider Processing of Authorization Requests (alle Authentisierungsverfahren) Internet
    IDP.UC_32 sektoraler Identity Provider Response of Authorization Requests (mit online Ausweisfunktion) Internet
    IDP.UC_33 sektoraler Identity Provider Response of Authorization Requests (mit eGK und PIN) Internet
    IDP.UC_34 sektoraler Identity Provider Response of Authorization Requests (alternatives Authentisierungsverfahren) Internet
    IDP.UC_35 sektoraler Identity Provider Fehlermeldung mit Fehlercode siehe A_22826 Internet
    IDP.UC_39 sektoraler Identity Provider Token Requests Internet
    Hinweise: 
    Die Duration für IDP.UC_30 beginnt mit der Annahme des Pushed Authorization Request (PAR) vom Authorization-Server des Fachdienstes und endet mit der Übermittlung der "URI-PAR" zum Authorization-Server des Fachdienstes. Zeiten zwischen der optionalen Anfrage "Get Entity Statement RP" des sektoralen IDP an den Fachdienst und der Antwort "Entity Statement" sowie der optionalen Anfrage "Fetch Entity Statement RP" des sektoralen IDP an den Federation Master und Antwort "Entity Statement" sind in der Berechnung für den IDP.UC_30 herauszurechnen.

    Die Duration für IDP.UC_31 beginnt mit der Annahme des Authorization Request (URI-PAR) vom Authenticator-Modul und enden mit dem Absenden der Anfrage zur Authentifizierung.
    Die Duration für IDP.UC_32 - IDP.UC_34 beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung  und endet mit der Übermittlung der "Redirect to redirect url, AUTH_CODE" zum Authenticator-Modul. 
    Die Duration für IDP.UC_35  beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung  und endet mit der Übermittlung eines Fehlercodes an die Betriebsdatenerfassung.
    Die Duration für IDP.UC_39 beginnt mit der Annahme des AUTH_CODE vom Authorization-Server des Fachdienstes und endet mit der Übermittlung des ID_TOKEN (ACCESS_TOKEN) zum Authorization-Server  des Fachdienstes.
    [<=]

    A_22016-01 - Performance - Rohdaten - Spezifika IDP - Message (Rohdatenerfassung v.02)

    Der Produkttyp MUSS - bei Rohdaten-Performance-Berichten bzgl. der "message"-Felder - den Useragent im JSON-Format übermitteln:
           {"UA":"$useragent"}
    Für $useragent ist der entsprechende Wert einzutragen, welcher vom Client übermittelt wird. [<=]

    A_22504 - Performance - Rohdaten - Spezifika IDP - Feldtrennzeichen im Useragent (Rohdatenerfassung v.02)

    Der Produkttyp MUSS, sofern vom Client irrtümlicherweise im Useragent-Wert das verbotene Feldtrennzeichen ";"  übertragen wurde, dieses ";" gegen das Zeichen "┼" austauschen und in der Rohdatenlieferung senden.
    (siehe: A_21981: Feldtrennzeichen  ";"
    Das Zeichen     ist definiert gem.  Unicode U+253C (9532) - BOX DRAWINGS LIGHT VERTICAL AND HORIZONTAL - ALT-Code 197)
    [<=]

    A_21340-01 - IDP- Abbruch bei OCSP-Timeout

    Der Produkttyp IdP-Dienst MUSS nach einer konfigurierbaren Wartezeit von 1100 msec auf die Antwort des OCSP den Vorgang abbrechen und diesen Abbruch gemäß [gemSpec_Perf#A_22015] und [Tab_gemSpec_Perf_Fehlercodes#"OCSP_ERROR_NO_RESPONSE"] in den Rohdaten protokollieren.
    [<=]

    Abbrüche des Anwendungsfalls können so differenziert erfasst werden. In den Fällen, bei denen die OCSP-Anfrage des zuständigen TSP zu spät beantwortet wird, erfolgt eine gesonderte Markierung in den Rohdaten. Dies ist notwendig zur Errechnung der Performancevorgaben des IDP. Hierbei werden diese Abbrüche nicht dem IDP angelastet.

    3.1.3 Bestandsdaten sektoraler IDP

    A_23213 - Registrierungsbestandsdaten - sektoraler IDP

    Der sektorale IDP MUSS die Registrierungsinformationen jeweils täglich zur betriebsarmen Abendzeit vor 24:00 Uhr im JSON Format [gemäß A_23236] als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß gemSpec_SST_LD_BD liefern.

    Hinweis:
    "Da bei dieser Lieferung keine Datei übermittelt wird, sondern der Text direkt im Body, ist für diese Lieferung die Angabe des filenames im HTTP Header gemäß [A_17733-01] (Tabelle: Tab_I_OpsData_Update_002 Operation I_OpsData_Update::fileUpload) in der gemSpec_SST_LD_BD NICHT notwendig."
    [<=]

    A_23236-03 - Format der Registrierungsinformationen des IDP

    Der sektorale IDP MUSS bei der Lieferung der Registrierungsinformationen folgendes Format verwenden:
    {
    "abfragezeitpunkt": "<Zeitstempel der Abfrage als String im ISO 8601 Format>",
    "ci": "<CI ID des abgefragten IDP gemäß TI-ITSM; als String>",
    "dailyUser":<Anzahl der Nutzer aller Mandanten, die den IDP einmal pro Tag nutzen; als Integer>,
    "powerUser":<Anzahl der Nutzer aller Mandanten, die den IDP mehr als einmal pro Tag nutzen; als Integer>,
    "bestand":
    [  
       {"regUser":
         [
           {"ident":"eGK", "anzahl":<Anzahl der zum Abfragezeitpunkt registrierten Nutzer des Mandanten als Integer mit Identifizierungsmittel eGK; als Integer>},
           {"ident":"nPA", "anzahl":<Anzahl der zum Abfragezeitpunkt registrierten Nutzer des Mandanten als Integer mit Identifizierungsmittel nPA; als Integer>},
           {"ident":"kid", "anzahl":<Anzahl der zum Abfragezeitpunkt registrierten Nutzer des Mandanten als Integer mit dem Identifizierungsverfahren: Kassenident; als Integer>},
           {"ident":"aid", "anzahl":<Anzahl der zum Abfragezeitpunkt registrierten Nutzer des Mandanten als Integer mit dem Identifizierungsverfahren: Apothekenident; als Integer>},
           {"ident":"pid", "anzahl":<Anzahl der zum Abfragezeitpunkt registrierten Nutzer des Mandanten als Integer mit dem Identifizierungsverfahren: Postident; als Integer>},
           {"ident":"nid", "anzahl":<Anzahl der zum Abfragezeitpunkt registrierten Nutzer des Mandanten als Integer mit dem Identifizierungsverfahren: Notarident; als Integer>},
           {"ident":"bid", "anzahl":<Anzahl der zum Abfragezeitpunkt registrierten Nutzer des Mandanten als Integer mit dem Identifizierungsverfahren: Behördenident; als Integer>}
          ]

         }
       ]
    }


    Hinweise:
    Nur wenn Elemente (Identifizierungsverfahren wie nPA, kid, nid, ...) tatsächlich verwendet werden, müssen diese innerhalb der Werteliste [ ] aufgeführt werden.
    Weitere Ident-Verfahren können in Absprache dem Schema folgend erweitert werden.
    Die Anzahl der "powerUser" wird auch in der Anzahl der "dailyUser" mit erfasst.
    [<=]

    3.2 E-Rezept

    3.2.1 Leistungsanforderungen E-Rezept

    3.2.1.1 Lastmodell E-Rezept

    Die Anwendungsfälle zum E-Rezept setzen den Workflow der Verordnung von apothekenpflichtigen Arzneimitteln um. Dabei werden die folgenden performance-relevanten Anwendungsfälle gemäß [gemSpec_FD_eRp] betrachtet:

    Bei jedem der genannten UseCases wird von einer existierenden, authentifizierten Nutzer-Session ausgegangen. Die jeweils übertragene Datenmenge hängt von der Anzahl der transportierten E-Rezepte ab. Je Anwendungsfall wird von einer Datenmenge von 10 kByte ausgegangen.

    Die Tabelle "Tab_Lastmodell E-Rezept aus der LE-U für Praxen, Apotheken und Versicherte" stellt eine Übersicht über die zu erwartenden Nutzungsraten für das E-Rezept dar. In der Lastbetrachtung wird von 4,8 Mio. ausgestellten und 3,7 Mio eingelöste Verordnungszeilen pro Tag ausgegangen. Das entspricht dem höchsten Aufkommen von Rezepten an einem Tag im Jahre 2018. Ebenfalls wird je Patient mit 1,4 Verordnungen (gerundet auf 2) kalkuliert.

    Tabelle 11: Tab_Lastmodell E-Rezept aus der LE-U für Praxen, Apotheken und Versicherte

    Anwendungsfall
    Datenmenge
    pro Anwendungs-fall in KByte
    Mengen-größe x
    Spitzenlasten pro Tag
    Spitzenlast- erhöhungs-faktor
    E-Rezept durch Verordnenden erzeugen
    10
     x: (M2+M3)
    25 * x
    2
    E-Rezept durch Verordnenden einstellen
    10
    25 * x
    2
    E-Rezept durch Abgebenden
    abrufen

    10
    x: M27
    65 * x
    2
    Nachricht durch Abgebenden übermitteln/empfangen
    10
    20 * x
    2
    Abgabe durch Abgebenden  vollziehen
    10
    x: M25
    182 * x
    1
    E-Rezept durch Versicherten
    abrufen

    10
    x: 2,4 Mio
    Versicherte
    2 * x
    2

    Nachricht durch Versicherten übermitteln/empfangen
    10
    0,6  x
    -

    Zur Ermittlung der Last in der (Zahn-)Arztpraxis/Krankenhaus wird die Anzahl der verordnenden Leistungserbringer zugrunde gelegt, da für die Verordnung zwingend ein Heilberufsausweis für die QES benötigt wird und ebenso nur Ärzte/Zahnärzte zur Verordnung von Medikamenten berechtigt sind.

    Der Vollzug der Abgabe durch den Abgebenden erfordert eine weitere Signatur durch einen Heilberufler bzw. in besonderen Fällen eine QES durch den Apotheker, weshalb hier M25 anstelle von M27 betrachtet wird.

    In der Kommunikation zwischen Apotheken und Versicherten zur Abfrage der Verfügbarkeit von Medikamenten wird von einer Nutzungsrate von 30% ausgegangen.

    3.2.1.2 Bearbeitungszeiten E-Rezept

    Für das E-Rezept müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall" angegebenen Mittelwerten sein.

    Tabelle 12: Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall

    ID
    Anwendungsfall
    Datenmenge
    [KB]
    Mittelwert
    [sec]
    ERP.UC_2_1
    E-Rezept durch Verordnenden erzeugen
    10
    2,3
    ERP.UC_2_3
    E-Rezept durch Verordnenden einstellen mit Flowtype 160
    10
    1,3
    ERP.UC_2_3_169 E-Rezept durch Verordnenden einstellen mit Flowtype 169 10 1,3
    ERP.UC_2_3_200 E-Rezept PKV einstellen 10 1,3
    ERP.UC_2_3_209 E-Rezept PKV (Direktzuweisung) einstellen 10 1,3
    ERP.UC_3_1 Nachrichten durch Abgebenden übermitteln/empfangen 10 1,3
    ERP.UC_3_3 Nachrichten durch Versicherten übermitteln/empfangen 10 1,3
    ERP.UC_3_7 Abrechnungsinformationen durch den Versicherten abrufen 20 1,4
    ERP.UC_4_1
    E-Rezept durch Abgebenden abrufen
    10
    3,1
    ERP.UC_4_4 E-Rezept durch Versicherten abrufen 10 0,7
    ERP.UC_4_7
    Abgabe durch Abgebenden vollziehen
    10
    1,3
    ERP.UC_4_10 Abrechnungsinformationen durch Abgebenden abrufen 10 3,1
    ERP.UC_4_11 Abrechnungsinformationen durch Abgebenden bereitstellen 10 1,3

    Die ID aus der Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" referenziert auf den entsprechenden Anwendungsfall gemäß [gemSysL_eRp].

    Die erhöhte Bearbeitungszeit bei den Anwendungsfällen zur Erstellung eines E-Rezepts beim Verordnenden und dem Abruf eines Rezeptes beim Abgebenden sind daraus zu begründen, dass hier die Konnektor-Operationen für das QES-Signieren und QES-Verifizieren von 10 KB-Dokumenten enthalten sind.

    Ebenfalls ist die erhöhte Bearbeitungszeit daraus zu begründen, dass ist in der Modellbetrachtung von einer Transportanbindung von 1024 kbit/sec in Download-Richtung und 128 kbit/sec in Upload-Richtung für die Leistungserbringer-Umgebung sowie für die des Versicherten ausgegangen wird.

    (*) In der Bearbeitungszeit wird mit dem aktuellen Referenzwert für die QES-Erstellung gerechnet, da noch keine Aussage zur Bearbeitungsdauer der QES-Erstellung mittels Komfortsignatur getroffen werden kann.

    Hinweis: In den Bearbeitungszeitvorgaben der jeweiligen Anwendungsfällen ist die Ausstellung der ID-Tokens des Identity Providers nicht berücksichtigt.

    3.2.1.3 Performancevorgaben E-Rezept

    A_20165-05 - Performance – E-Rezept-Fachdienst - Bearbeitungszeit unter Last

    Der Produkttyp E-Rezept-Fachdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.


    Tabelle 13 Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben

    UseCase-Bezug
    Fachdienstoperation
    Spitzenlast
    [1/sec]
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    ERP.UC_2_1
    POST /Task/$create
    390
    460
    620
    ERP.UC_2_3
    POST /Task/<id>/$activate mit Flowtype 160
    335
    400
    550
    ERP.UC_2_3_169 POST /Task/<id>/$activate mit Flowtype 169 5 400 550
    ERP.UC_2_3_200 POST /Task/<id>/$activate mit Flowtype 200 50 400 550
    ERP.UC_2_3_209 POST /Task/<id>/$activate mit Flowtype 209 5 400 550
    ERP.UC_3_1
    GET /Task
    310
    410
    665
    ERP.UC_3_3
    POST /Communication
    50
    380
    525
    ERP.UC_3_7 GET /ChargeItem/<id> mit Rolle oid_versicherter 40 420 575
    ERP.UC_4_1
    POST /Task/<id>/$accept
    240
    455
    615
    ERP.UC_4_4
    POST /Task/<id>/$close
    120
    375
    520

    ERP.UC_4_7
    POST /Communication
    75
    380
    525
    ERP.UC_4_10 GET /ChargeItem/<id> mit Rolle oid_oeffentliche_apotheke oder oid_krankenhausapotheke 30 420 575
    ERP.UC_4_11 POST /ChargeItem 30 375 520
    [<=]

    Die ID aus der Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" referenziert auf den entsprechenden Anwendungsfall gemäß [gemSysL_eRp]. Die in der Tabelle definierten Bearbeitungszeiten beziehen sich auf die vom Fachdienst umzusetzenden Operationen in den referenzierten Anwendungsfällen.

    A_20166 - Performance - E-Rezept-Fachdienst - Robustheit gegenüber Lastspitzen

    Der E-Rezept Fachdienst MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" verfügbar bleiben.
    [<=]

    Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der E-Rezept-Fachdienst vorübergehend abweisen. Dabei müssen die definierten Spitzenlasten weiterhin innerhalb der Performancevorgaben verarbeitet werden. Vom System angenommene Anfragen müssen weiterhin innerhalb der Performancevorgaben verarbeitet werden. Der Anbieter des Fachdienstes hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.

    A_19737 - Performance E-Rezept-Fachdienst - Skalierung

    Der Anbieter des E-Rezept Fachdienstes MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird.
    [<=]

    Im Zuge des Zulassungsverfahrens hat der Anbieter des E-Rezept-Fachdienstes der gematik gegenüber nachvollziehbar darzustellen, welche technischen Skalierungsmaßnahmen anhand welcher messbarer Parameter er für den Produktivbetrieb plant durchzuführen. Die Skalierungsmaßnahmen können dabei unterschiedliche Ausprägungen und Dimensionen umfassen. Beispielsweise eine automatisierte Ressourcenzuteilung oder eine Anpassung oder Änderung unterschiedlicher technischer Komponenten, die zu einer Produktänderung im Sinne der [gemSpec_OM] führt. Die Darstellung muss Verifikationsbeschreibungen enthalten, mit denen der Erfolg der Maßnahmen ermittelt werden kann.

    A_19736-01 - Performance - E-Rezept-Fachdienst - Verfügbarkeit

    Der Anbieter des E-Rezept-Fachdienstes MUSS zur Hauptzeit eine Verfügbarkeit von 99,99% und zur Nebenzeit von 99,97% für alle Operationen der technischen Schnittstellen aufweisen.

    Wartungsfenster MÜSSEN vollständig in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.

    Die Anschlüsse aller Standorte an das zentrale Netz MÜSSEN über die Anschlussoption "Hohe Verfügbarkeit" erfolgen.
    [<=]

    Die Verfügbarkeit der funktionalen Eigenschaften des E-Rezept-Fachdienstes wird mittels der Probes des Service Monitorings und die nicht funktionalen Eigenschaften durch Auswertung der Rohdaten ermittelt.

    A_19735-02 - Performance - Erfassung von Rohdaten - E-Rezept-Fachdienst

    Der Produkttyp E-Rezept-Fachdienst MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst" erfassen und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an die Betriebsdatenerfassung gemäß [A_17678] liefern. [<=]

    A_19734 - Performance - Lieferung von Rohdaten - E-Rezept-Fachdienst

    Der Anbieter E-Rezept-Fachdienst MUSS das Produkt E-Rezept-Fachdienst so konfigurieren, dass dieses in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte und die Datei zur Selbstauskunft automatisiert an die Betriebsdatenerfassung gemäß [A_17678] liefert. Voreingestellt für das Zeitintervall ist 60 Minuten. [<=]

    3.2.2 Rohdaten-Performance-Reporting Spezifika E-Rezept

    In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.

    3.2.2.1 Umfang

    A_22975 - Performance - Rohdaten-Performance-Bericht - Konfiguration pseudonymisierte Werte der Telematik-ID

    Der Produkttyp E-Rezept-Fachdienst MUSS eine Konfiguration unterstützen, welche die Funktionalität zur Erfassung und Übermittlung der pseudonymisierten Werte der Telematik-ID der Leistungserbringerinstitutionen ein- bzw. abschaltet. 
    [<=]

    A_22976 - Performance - Rohdaten-Performance-Bericht - Steuerung Konfiguration pseudonymisierte Werte der Telematik-ID

    Der Anbieter des E-Rezept-Fachdienstes MUSS die Konfiguration für die Funktionalität zur Erfassung und Übermittlung der pseudonymisierten Werte der Telematik-ID der Leistungserbringerinstitutionen entsprechend den Vorgaben der gematik vornehmen. [<=]

    3.2.2.2 Format

    A_23088 - Performance - Rohdaten - Spezifika E-Rezept - Operation (Rohdatenerfassung v.02)

    Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "operation" die Angabe der Spalte "$FD-operation" aus Tabelle [gemSpec_Perf#Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst] berücksichtigen.
    Sollte die Operation des inneren Requests nicht ermittelt werden können, so ist stattdessen für das Feld "operation" der Wert "ERP.VAU" zu verwenden. [<=]

    A_23089 - Performance - Rohdaten - Spezifika E-Rezept - Status (Rohdatenerfassung v.02)

    Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "status" die Angabe der Spalte "HTTP-Status-Code" gemäß A_19514-* aus [gemSpec_FD_eRp] berücksichtigen.  [<=]

    A_23090 - Performance - Rohdaten - Spezifika E-Rezept - Message (Rohdatenerfassung v.02)

    Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen.

    { "cid": "$clientid", "ua": "$useragent", "leip": "$leipseudonym" }

    Bei der Erstellung des message-Feldes ist darauf zu achten, dass weder Whitespaces noch Newlines zwischen JSON-Elementen enthalten sind (kein Indenting) und Vorgaben nach [RFC7493] eingehalten werden. [<=]

    A_23091 - Performance - Rohdaten - Spezifika E-Rezept - Duration (Rohdatenerfassung v.02)

    Der Produkttyp E-Rezept-Fachdienst MUSS bei Rohdaten-Performance-Berichten bzgl. des Feldes "duration_in_ms" die folgende Festlegung bei der Angabe von Bearbeitungszeiten berücksichtigen:
    Die Messung beginnt mit der vollständigen Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem ersten Bit der Antwortnachricht an den Empfänger. [<=]

    Tabelle 14 Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst

    $FD-operation
    Operation
    Schnittstelle zu
    ERP.UC_1_1 GET /Device alle
    ERP.UC_1_2 GET /metadata alle
    ERP.UC_2_1
    POST /Task/$create
    verordnende LEI
    ERP.UC_2_3
    POST /Task/<id>/$activate mit Flowtype 160
    verordnende LEI
    ERP.UC_2_3_169 POST /Task/<id>/$activate mit Flowtype 169 verordnende LEI
    ERP.UC_2_3_200 POST /Task/<id>/$activate mit Flowtype 200 verordnende LEI
    ERP.UC_2_3_209 POST /Task/<id>/$activate mit Flowtype 209 verordnende LEI
    ERP.UC_2_5 POST /Task/<id>/$abort verordnende LEI
    ERP.UC_3_1 GET /Task Versicherte
    ERP.UC_3_2 POST /Task/<id>/$abort Versicherte
    ERP.UC_3_3 POST /Communication Versicherte
    ERP.UC_3_5 GET /AuditEvent Versicherte
    ERP.UC_3_6 GET /Task/<id> Versicherte
    ERP.UC_3_7 GET /ChargeItem/<id> Versicherte
    ERP.UC_3_8 DELETE /Communication/<id> Versicherte
    ERP.UC_3_9 GET /MedicationDispense?<parameter>= Versicherte
    ERP.UC_3_10 GET /ChargeItem Versicherte
    ERP.UC_3_11 DELETE /ChargeItem/<id> Versicherte
    ERP.UC_3_12 PATCH /ChargeItem Versicherte
    ERP.UC_3_13 GET /Consent Versicherte
    ERP.UC_3_14 POST /Consent Versicherte
    ERP.UC_3_15 DELETE /Consent Versicherte
    ERP.UC_4_1 POST /Task/<id>/$accept abgebende LEI
    ERP.UC_4_2 POST /Task/<id>/$reject abgebende LEI
    ERP.UC_4_3 POST /Task/<id>/$abort abgebende LEI
    ERP.UC_4_4 POST /Task/<id>/$close abgebende LEI
    ERP.UC_4_7 POST /Communication
    abgebende LEI
    ERP.UC_4_8 GET /Task/<id> abgebende LEI
    ERP.UC_4_9 DELETE /Communication/<id> abgebende LEI
    ERP.UC_4_10 GET /ChargeItem/<id> abgebende LEI
    ERP.UC_4_11 POST /ChargeItem abgebende LEI
    ERP.UC_4_12 GET /Task abgebende LEI
    ERP.UC_4_13 PUT /ChargeItem abgebende LEI
    ERP.UC_4_14 POST /Subscription abgebende LEI
    ERP.nonVAU_1 GET /VAUCertificate alle
    ERP.nonVAU_2 GET /VAUCertificateOCSPResponse alle
    ERP.nonVAU_3 GET /CertList alle
    ERP.nonVAU_4 GET /OCSPList alle
    ERP.nonVAU_5 POST /ocspf alle

    3.2.3 Bestandsdaten

    A_22520 - Performance – E-Rezept-Fachdienst - Bestandsdaten

    Der Anbieter E-Rezept-Fachdienst MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Performance-Kenngrößen über den E-Rezept-Fachdienst berichten:

    Der Anbieter E-Rezept-Fachdienst MUSS die Bestandsdaten an den Endpunkt gemäß [gemSpec_SST_LD_BD] liefern.
    Voreingestellt für das Zeitintervall ist: täglich.
    [<=]

    A_22521 - Performance - E-Rezept-Fachdienst - Lieferweg und Format für Bestandsdaten

    Der Anbieter E-Rezept-Fachdienst MUSS die Informationen aus A_22520 jeweils zum Wechsel in den nächsten Berichtsintervall in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß gemSpec_SST_LD_BD liefern:
    {
                    „Abfragezeitpunkt“: <Zeitstempel der Abfrage als String im ISO 8601 Format>,
                    „CI_ID“: <CI ID des abgefragten Fachdienstes gemäß TI-ITSM als String>,
                    „eRP_Anzahl_Rezepte“: <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte als Integer>,
                    „eRP_Anzahl_Status_Draft“: <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Draft als Integer>,
                    „eRP_Anzahl_Status_Ready“: <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Ready als Integer>,
                    „eRP_Anzahl_Status_Inprogress“: <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Inprogress als Integer>,
                    „eRP_Anzahl_Status_Completed“: <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Completed als Integer>,
                    „eRP_Anzahl_Status_Cancelled“: <Anzahl der zum Abfragezeitpunkt vorhandenen E-Rezepte im Status Cancelled als Integer>,
                    „eRP_Menge_NichtBenutzt“: <Anzahl der im Berichtsintervall aufgrund von Löschfristen entfernten und nicht eingelösten E-Rezepte als Integer>,
                    „eRP_Mittelwert_Laufzeit_min“: <Mittelwert der Laufzeit der im Berichtsintervall abgeschlossenen E-Rezepte in Minuten als Integer>,
                    „eRP_max_Anzahl_Subscriptions“: <Maximale Anzahl gleichzeitiger Sessions an der Subscription Schnittstelle im Berichtsintervall als Integer>,
                    „eRP_Menge_Operationen“: <Anzahl der im Berichtsintervall aufgerufenen Operationen am Fachdienst als Integer>,
                    „eRP_max_Spitzenlast_Hz“: <Maximaler Wert der Spitzenlast (1/s) im Berichtsintervall als Integer>,
                    „eRP_Menge_UC46“: <Anzahl der im Berichtsintervall aufgerufenen UC 4.6 Operationen am Fachdienst als Integer>

    }

    [<=]

    Da bei dieser Lieferung keine Datei übermittelt wird, sondern der Text direkt im Body, ist für diese Lieferung die Angabe des filenames im HTTP-Header gemäß [A_17733-01] (Tabelle: Tab_I_OpsData_Update_002 Operation I_OpsData_Update::fileUpload) in der gemSpec_SST_LD_BD NICHT notwendig.

    3.3 TI-Messenger (TI-M)

    Dieses Kapitel dient der Ergänzung der TI-Messenger (TI-M) Spezifikationen [gemSpec_TI-Messenger-Dienst], [gemSpec_TI-Messenger-FD] und [gemSpec_TI-Messenger-Client]. Der gesamte Anforderungshaushalt inkl. Referenzen auf weitere normative Dokumente an die jeweiligen TI-M Produkte und Anbieter findet sich in diesen Dokumenten als auch in den entsprechenden Produkt- bzw. Anbietertypsteckbriefen.

    3.3.1 Verfügbarkeit

    A_23116 - TI-M Fachdienst Verfügbarkeit (Produkt)

    Der TI-Messenger-Fachdienst MUSS mit einer vollumfänglich-funktionalen Verfügbarkeit von mindestens 99,8 % betreibbar sein. [<=]

    A_23117 - TI-M Fachdienst Verfügbarkeit (Anbieter)

    Der Anbieter TI-Messenger MUSS sein Produkt TI-Messenger-Fachdienst mit einer vollumfänglich-funktionalen Verfügbarkeit von 99,8% in der Hauptzeit und 99,0 % in der Nebenzeit betreiben.
    Die Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Zeiten gelten als Nebenzeit.

    Wenn der Betrieb von Homeservern on-premise bei den Nutzern realisiert wird, KANN der Anbieter TI-Messenger für diese Produktinstanzen von den Performancevorgaben in Abstimmung mit seinen Kunden abweichen. Die Abweichungen und die betroffenen Instanzen MÜSSEN dem GTI im Rahmen der betrieblichen Prozesse bekannt gemacht werden.
    [<=]

    3.3.2 Rohdaten

    A_22946 - Rohdatenerfassung und -lieferung

    Der TI-Messenger-Fachdienst MUSS die Rohdatenerfassung und -lieferung entsprechend der Vorgaben aus [gemSpec_Perf#Rohdaten-Performance-Reporting (Rohdatenerfassung v.02)] umsetzen.
    Die Rohdatenerfassung am TI-Messenger-Fachdienst SOLL anhand entsprechend [Tab_gemSpec_Perf_Berichtsformat_TI-Messenger-Fachdienst <3] erfolgen.
    [<=]

    *1) Hinweis: Die Beschreibung entspricht dem Ende eines erfolgreichen Anwendungsfalls. Wenn der Anwendungsfall abbricht und/oder eine Fehlermeldung erzeugt, so MUSS im JSON-message-Block für das Feld httpStatus der negative http-Statuscode entsprechend der Beschreibung im Anwendungsfall eingetragen werden. Für jede Anwendungsfall-Instanz MUSS eine eindeutige ID vergeben werden. Die ID KANN mit einem Abstand von 6 Monaten neu vergeben werden um die Operationen innerhalb eines Anwendungsfalls konsolidieren zu können und gleichzeitig von anderen Anwendungsfall-Instanzen abzugrenzen.

    A_22940 - Performance - Rohdaten - Spezifika TI-M Message (Rohdatenerfassung v.02)

    Das Produkt SOLL - bei Rohdaten-Performance-Berichten im "message"-Feld – folgende Informationen im JSON-Format übermitteln:

    {
    "Instanz-ID":$Instanz-ID,
    "Useragent":
      {
        "Produkttypversion": $Produkttypversion,
        "Produktversion": $Produktversion,
        "Auspraegung": $Auspraegung,
        "Plattform": $Plattform,
        "OS": $OS,
        "OS-Version": $OS-Version,
        "client_id": $client_id,
        "Matrix-Domain: $Matrix-Domain
      },
    "Matrix-Domain":$Matrix-Domain,
    "sizeIn":$sizeIn,
    "sizeOut":$sizeOut,
    "telematikID":$telematikID,
    "professionOID":$professionOID,
    "Response":$response
    }


    Für $Instanz-ID ist eine für jede Instanz eines Anwendungsfalls gleichbleibende ID einzutragen.
    Die Instanz-ID SOLL somit für die jeweiligen Operationen bzw. Teilschritte innerhalb einer Instanz eines Anwendungsfalls gleich vergeben werden.
    Für $useragent sind die entsprechenden Werte einzutragen, welche vom Client übermittelt werden. Falls die Anfrage von einem Matrix-Server kommt, ist hier ausschließlich die Matrix-Domain des Senders einzutragen.
    Für $Auspraegung sind ausschließlich die Werte "Org-Admin-Client" und "Messenger-Client" entsprechend der TI-M Client Spezifikation erlaubt.
    Für $Plattform sind ausschließlich die Werte "mobil", "stationaer", "web" entsprechend der TI-M Client Spezifikation erlaubt.
    Für $OS ist das entsprechende Betriebssystem einzutragen, z.B. Windows, iOS, MacOS, Android, GNU/Linux.
    Für $OS-Version ist die Version des Betriebssystems einzutragen.
    Für $client_id ist die client_id einzutragen wie sie auch dem IdP übermittelt wird.
    Für $Matrix-Domain ist die eigene Matrix-Domain des Messenger-Services einzutragen.
    Für $sizeIn ist das eingehende übertragene Datenvolumen in Byte als Integer anzugeben. Der Messpunkt beim TI-Messenger-Fachdienst ist dabei der Messenger-Proxy und beim FHIR-Directory der FHIR-Proxy.
    Für $sizeOut ist das ausgehende übertragene Datenvolumen in Byte als Integer anzugeben. Der Messpunkt beim TI-Messenger-Fachdienst ist dabei der Messenger-Proxy und beim FHIR-Directory der FHIR-Proxy.
    Für die $telematikID ist die telematikID aus dem entsprechenden Token einzutragen.
    Für die $professinoOID ist die professionOID aus dem entsprechenden Token einzutragen.
    Für die $response ist der Statuscode als Rückmeldung der entsprechenden Anwendungsfälle einzutragen. [<=]

    Bestandsdaten

    A_23119 - TI-Messenger Fachdienst Bestandsdaten

    Der TI-Messenger-Fachdienst MUSS die nachfolgenden Informationen jeweils monatlich zum 01. des Monats in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß [gemSpec_SST_LD_BD] liefern:

    {
        „Abfragezeitpunkt“: <Zeitstempel der Abfrage als String im ISO 8601 Format>,
        „CI_ID“: <CI ID des abgefragten Fachdienstes gemäß TI-ITSM als String>,
        „TIM-FD_Anzahl_Messenger-Service“: <Anzahl der zum Abfragezeitpunkt instanziierten Messenger-Service>,
        „TIM-FD_Anzahl_Nutzer“: <Anzahl der zum Abfragezeitpunkt registrierten Nutzer>,
        „TIM-FD_Anzahl_aktNutzer“: <Anzahl der zum Abfragezeitpunkt innerhalb des letzten Monats aktiven Nutzer>

    }
    [<=]

    3.4 TSP X.509

    Im folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat der TSP X.509 aufgeführt.

    3.4.1 Leistungsanforderungen TSP X.509

    3.4.1.1 Lastmodell TSP X.509

    [Das Verschieben der Vorgaben im Rahmen der Umstrukturierung des Dokumentes erfolgt im Nachgang]

    [Die Vorgaben befinden sich aktuell im Kapitel ]

    3.4.1.2 Bearbeitungszeiten TSP X.509

    [Das Verschieben der Vorgaben im Rahmen der Umstrukturierung des Dokumentes erfolgt im Nachgang]

    3.4.1.3 Performancevorgaben TSP X.509

    [Das Verschieben der Vorgaben im Rahmen der Umstrukturierung des Dokumentes erfolgt im Nachgang]

    [Die Vorgaben befinden sich aktuell in den Kapiteln  und ]

    3.4.2 Rohdaten-Performance-Reporting Spezifika TSP X.509

    In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.

    3.4.2.1 Umfang

    keine Spezifischen Anforderungen zum Umfang

    3.4.2.2 Format

    A_22489 - Performance - Rohdaten - Spezifika TSP X.509 - Duration (Rohdatenerfassung v.02)

    Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSP-X.509 berücksichtigen. [<=]

    A_22490 - Performance - Rohdaten - Spezifika TSP X.509 - Operation (Rohdatenerfassung v.02)

    Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_TSP-X.509 berücksichtigen. [<=]

    Tabelle 15: Tab_gemSpec_Perf_Berichtsformat_TSP-X.509

    Operation/Usecase Produkttyp
    Duration
    TSP.UC_1_Q TSP-X.509QES
    Bei Aufruf der Operation check_Revocation_Status beginnt die Messung mit der Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht. 
    TSP.UC_2_nQ TSP-X.509nonQES
    Bei Aufruf der Operation check_Revocation_Status beginnt die Messung mit der Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht. 

    A_22491 - Performance - Rohdaten - Spezifika TSP X.509 - Status (Rohdatenerfassung v.02)

    Wenn bei der Durchführung der Operation / des Usecase ein Fehler aufgetreten ist, MUSS der Produkttyp - bei Rohdaten-Performance-Berichten bzgl. des "status"-Feldes - den Statuscode gem. Tab_gemSpec_Perf_Fehlercodes_TSP-X.509 festlegen, sofern ein spezifischer Fehlercode bestimmt werden kann. Ist dies nicht möglich MUSS der definierte Standardcode für interne bzw. externe Fehler verwendet werden.

    Tabelle #: Tab_gemSpec_Perf_Fehlercodes_TSP-X.509
    Statuscode
    Definition
    Beschreibung
    79875
    OCSP_ERROR_WRONG_DATA
    Format der OCSP-Anfrage fehlerhaft
    [<=]

    A_22492 - Performance - Rohdaten - Spezifika TSP X.509 - Message (Rohdatenerfassung v.02)

    Der Produkttyp MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern die Rückgabewerte der Abfrage des Sperrstatus der jeweiligen X.509 Zertifikate im JSON-Format übermitteln:
           {"Sperrstatus":"$status"}
    Für $status ist der entsprechende Sperrstatus-Wert gemäß Tab_gemSpec_Perf_Sperrstatus_Werte_TSP-X.509 einzutragen, welcher für das jeweilige Zertifikat ermittelt wurde.

    Tab_gemSpec_Perf_Sperrstatus_Werte_TSP-X.509
    Sperrstatus
    GOOD
    REVOKED
    UNKNOWN
    [<=]

    3.5 IDP-Federation Master

    3.5.1 Leistungsanforderungen IDP-Federation Master

    3.5.1.1 Lastmodell IDP-Federation Master
    3.5.1.2 Bearbeitungszeiten IDP-Federation Master
    3.5.1.3 Performancevorgaben IDP-Federation Master

    A_22957 - Performance – FedMaster – Verfügbarkeit

    Der Anbieter des Federation Master MUSS sein Produkt so betreiben, dass es zur Hauptzeit und zur Nebenzeit mindestens eine Verfügbarkeit von 98,40 % hat.
    Genehmigte Wartungsfenster dürfen nur in der Nebenzeit liegen und werden nicht als Ausfallzeit gewertet.
    Hauptzeit des Produkttyps ist Montag bis Sonntag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
    [<=]

    A_22950 - Performance – FedMaster – Bearbeitungszeit unter Last

    Der Produkttyp Federation Master MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_FedMaster erfüllen.
    Es wird davon ausgegangen, dass der Federation Master eingeschwungen ist und z.B. Verbindungen nicht neu ausgehandelt werden.
    Für die Zulassung ist je Anwendungsfall der Nachweis bei einer Last von 10 Anfragen pro Sekunde zu erbringen.

    Tabelle 16: Tab_gemSpec_Perf_FedMaster: Bearbeitungszeitvorgaben

    ID
    Anwendungsfälle
    Lastvorgaben
    Bearbeitungszeitvorgaben
    Spitzenlast
    [1/sec]
    Maximalwert
    [msec]
    FEDM.UC_1
    get_IDP_list (Internet)
    10
    20000
    FEDM.UC_2
    fetchEntityStatement (Internet)
    10
    20000
    Hinweise:
    Die Duration für FEDM.UC_1 beginnt mit der Annahme der getIDP_list-Anfrage und endet mit der Lieferung der IDP-Liste als Antwort zum Fachdienst.
    Die Duration für FEDM.UC_2 beginnt mit der Annahme der fetchEntityStatement-Anfrage und endet mit der Lieferung der StatementResponse als Antwort zum IDP.

    Es ist eine ausreichend großzügige Performance-Vorgabe von 20 Sekunden als Antwortzeit vorgegeben, jedoch darf diese in keinem Fall überschritten werden. Eine Quantil-Schranke wird nicht gewährt.

    [<=]

    3.5.2 Rohdaten-Performance-Reporting Spezifika IDP-Federation Master

    In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.

    3.5.2.1 Spezifika Umfang IDP-Federation Master
    3.5.2.2 Spezifika Format IDP-Federation Master

    A_23386 - Performance - Rohdaten - Spezifika FedM - Operation (Rohdatenerfassung v.02)

    Der Anbieter des Federation Master MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe aus der Tabelle 'Tab_gemSpec_Perf_FedMaster' in der Spalte "ID" verwenden.

    [<=]

    A_23489 - Performance - Rohdaten - Spezifika FedM - Duration (Rohdatenerfassung v.02)

    Der Produkttyp MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die konkretisierenden Hinweise unter der
    Tabelle Tab_gemSpec_Perf_FedMaster: Bearbeitungszeitvorgaben berücksichtigen. [<=]

    A_23387 - Performance - Rohdaten - Spezifika FedM - Message (Rohdatenerfassung v.02)

    Der Anbieter des Federation Masters MUSS - bei Rohdaten-Performance-Berichten bzgl. der "message"-Felder - den Useragent im JSON-Format übermitteln:
           {"UA":"$requesting_party"}

    Für $requesting_party ist MemberID des entsprechend registrierten IDP oder Fachdienst einzutragen.

    Hinweis:
    Die MemberID wird durch die gematik vergeben.

    [<=]

    3.6 VPN-Zugangsdienst

    Der Produkttyp VPN-Zugangsdienst verbindet Transportnetz und Zentrales Netz der TI. Für OCSP-Request sorgt er dabei für ein http-Forwarding.

    Zusätzlich zu dieser über die Schnittstelle I_Secure_Channel_Tunnel angebotenen Leistung, bietet der VPN-Zugangsdienst Leistungen über die Schnittstellen I_DNS_Name_Resolution und I_NTP_Time_Information an.

    3.6.1 Leistungsanforderungen VPN-Zugangsdienst

    3.6.1.1 Lastmodell VPN-Zugangsdienst

    keine Spezifischen Anforderungen zum Lastmodell

    3.6.1.2 Bearbeitungszeiten VPN-Zugangsdienst

    Für die Schnittstelle I_DNS_Name_Resolution gelten die Anforderungen wie für den Namensdienst:

     

    Für die Schnittstelle I_Secure_Channel_Tunnel gelten die folgenden Anforderungen:

    GS-A_4168 - Performance – VPN-Zugangsdienst – Bearbeitungszeit

    Der VPN-Zugangsdienst MUSS eine Laufzeit der IP-Pakete zwischen der Schnittstelle zum Transportnetz Internet und der Schnittstelle zum Zentralen Netz der TI von unter 20 ms aufweisen.

    Der VPN-Zugangsdienst MUSS eine Laufzeit der IP-Pakete zwischen der Schnittstelle zum Transportnetz Internet und der Schnittstelle zum Internet über den SIS von unter 20 ms aufweisen.

    [<=]

    3.6.1.3 Performancevorgaben VPN-Zugangsdienst

    Für die Schnittstelle I_DNS_Name_Resolution gelten die Anforderungen wie für den Namensdienst:

     

     

     

     

    Für die Schnittstelle I_NTP_Time_Information gelten die Anforderungen wie für den Zeitdienst:

     

     

     

     

     

    Für die Schnittstelle I_Secure_Channel_Tunnel gelten die folgenden Anforderungen:

    GS-A_4170 - Performance – VPN-Zugangsdienst – Durchsatz

    Der VPN-Zugangsdienst MUSS eine Anbindungsbandbreite an das zentrale Netz mit folgenden Eigenschaften bereitstellen:

    Der VPN-Zugangsdienst MUSS an jedem Standort auf der Strecke von den VPN-Konzentratoren zum SZZP eine Bandbreite von 10 GBit/sec durchgehend unterstützen.
    [<=]

    GS-A_5510 - Performance – VPN-Zugangsdienst – IPSec-Tunnel TI und SIS

    Der Produkttyp VPN-Zugangsdienst MUSS eine Anbindung zum Transportnetz von mindestens 1 Gbit/sec pro 10000 Konnektoren besitzen.

    Die VPN-Konzentratoren für SIS und TI MÜSSEN einen IPSec-Durchsatz unterstützten, der sich aus der Transportnetzanbindung ergibt.
    [<=]

    GS-A_5545 - Performance – VPN-Zugangsdienst – IPSec-Tunnel TI und SIS Konfigurationseinstellungen

    Der Produkttyp VPN-Zugangsdienst DARF den IPSec-Durchsatz der VPN-Konzentratoren pro Konnektor NICHT durch Konfigurationseinstellungen reduzieren.

    [<=]

    Die Anforderung [] verlangt eine Verfügbarkeit, die sowohl die primäre Leistung der Verbindung von Transportnetz und Zentralem Netz der TI mit Terminierung des VPN-Kanals beinhaltet, also auch DNS-Anfragen und http-Forwarding. Nicht inkludiert in der Verfügbarkeit ist wegen ihres asynchronen Beitrags zu Anwendungsfällen die NTP-Schnittstelle.

    Wie die Volumenmessungen zu erfolgen hat, regelt die nachfolgende Anforderung, siehe hierzu [gemKPT_Arch_TIP], Abbildung „Netzwerktopologie der TI“:

    GS-A_5015 - Performance – VPN-Zugangsdienst – Volumenmessung im SIS

    Der SIS des VPN-Zugangsdienstes der TI-Plattform MUSS das Volumen der übertragenen Daten getrennt nach Richtung zum Internet und vom Internet erfassen.

    [<=]

    Weitere Anforderungen:

     

     

     

     

    3.6.2 Rohdaten-Performance-Reporting Spezifika VPN-Zugangsdienst

    In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.

    3.6.2.1 Umfang

    keine Spezifischen Anforderungen zum Umfang

    3.6.2.2 Format

    A_23221 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Duration (Rohdatenerfassung v.02)

    Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "duration_in_ms"-Felder die Hinweise der Spalte "Duration" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_VPN-ZugD berücksichtigen. [<=]

    A_23222 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Operation (Rohdatenerfassung v.02)

    Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten bzgl. der "operation"-Felder die Angabe der Spalte "Operation/Usecase" aus Tabelle Tab_gemSpec_Perf_Berichtsformat_VPN-ZugD berücksichtigen. [<=]

    Tabelle #: Tab_gemSpec_Perf_Berichtsformat_VPN-ZugD

    Operation / Usecase Duration
    I_Secure_Channel_Tunnel::connect Bei Aufruf der Operation beginnt die Messung mit Annahme der Aufrufnachricht an der Außenschnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht. 
    I_Secure_Channel_Tunnel::disconnect -""-
    I_Registration_Service::registerKonnektor -""-
    I_Registration_Service::deregisterKonnektor -""-
    I_DNS_Name_Resolution::get_IP_Address -""-
    I_NTP_Time_Information::receive  -""-

    A_23220 - Performance - Rohdaten - Spezifika VPN-Zugangsdienst - Message (Rohdatenerfassung v.02)

    Der Produkttyp VPN-Zugangsdienst MUSS bei Rohdaten-Performance-Berichten in den "message"-Feldern aus der ID.VPNK.VPN die Elemente
    des Subject gemäß gemSpec_PKI#Tab_PKI_245 im JSON-Format übermitteln:
    {„CN“: $commonName, „SN“: $serialNumber, „ON“: $organizationName, „CN“: $countryName}
    [<=]

    4 Leistungsanforderungen für Anwendungsfälle

    Das vorliegende Kapitel erfasst die Leistungsanforderungen aus den Anwendungen der TI im Wirkbetrieb:

    Die Leistungsanforderungen werden hier der Reihe nach für die drei Performance-Dimensionen Last, Bearbeitungszeit und Verfügbarkeit aufgeführt.

    4.1 Spitzenlasten für Anwendungsfälle

    Ausgangspunkt für die Modellierung von Spitzenlasten auf Ebene der Anwendungsfälle ist ein Mengengerüst der Leistungserbringer in Praxen und Krankenhäuser sowie den gesetzlich Krankenversicherten und ihren Behandlungsfällen. Spitzenlasten für die Anwendungsfallnutzung berechnet das Lastmodell als Produkt aus Mengengröße und einem Proportionalitätsfaktor, welcher das bekannte und erwartete Benutzerverhalten widerspiegelt.

    Der Ansatz über die Proportionalitätsfaktoren erlaubt es, die Spitzenlasten an den jeweiligen Kontext anzupassen: für eine Praxis, für ein Krankenhaus einer bestimmten Größe oder für die TI insgesamt im Produktivbetrieb.

    4.1.1 Mengengerüst

    Im Folgenden wird das Mengengerüst für den Produktivbetrieb aufgestellt, welches alle gesetzlich Krankenversicherte bedient.

    Da letztlich die Leistungen des Gesundheitswesens für die Krankenversicherten erbracht werden, ist die Zahl des Versicherten die zentrale Mengengröße, mit der alle Mengenangaben skalieren. D. h. alle Lastangaben die sich im Folgenden auf alle 70 Mio. Versicherten beziehen, können auf kleinere Mengen heruntergerechnet werden – etwa pro 1 Mio. Versicherten, indem Lastangaben durch 70 geteilt werden.

    Die Tabelle "Tab_Mengengerüst: Versicherte und Leistungserbringer" gibt die Zahl der Versicherten, der niedergelassenen Leistungserbringer und der Krankenhäuser an. Es folgt eine Größenklassifizierung der Praxen in Tabelle "Tab_Mengengerüst: Lokationen" sowie der Krankenhäuser in Tabelle "Tab_Mengengerüst: Krankenhäuser". Die Tabelle "Tab_Mengengerüst: Annahmen für Modellierung"  trifft Annahmen zur Modellierung.

    Da die Lastbetrachtung große Unwägbarkeiten bzgl. des Benutzerverhaltens enthält, ist eine Signifikanz von 1-2 Stellen in den Zahlen des Mengengerüsts ausreichend. Die Zahlen sind daher entsprechend gerundet und beim Bezugszeitpunkt der Größen wird eine entsprechende Ungenauigkeit zugelassen.

    Tabelle 17: Tab_Mengengerüst: Versicherte und Leistungserbringer

    ID
    Größe
    Anzahl
    Quelle
    M1
    Gesetzlich Krankenversicherte
    der Bundesrepublik Deutschland 2008

     70.000.000
    [GBE_Bund]
    M2
    Ärzte
        138.500
    [KBV2010]
    M3
    Zahnärzte,
    die an der vertragszahnärztlichen Versorgung teilnehmen

         54.200
    [KZBV2010]
    M4
    Psychotherapeuten
         17.300
    [KBV2010]
    M27
    Apotheker,
    Apothekerassistenten und
    Pharmazieingenieure

         56.600
    [ABDA2018]
    M5
    Leistungserbringer (LE)
        266.600
    M2 + M3 + M4 + M27

    Tabelle 18: Tab_Mengengerüst: Lokationen

    ID
    Größe
    Anzahl
    Quelle
    M6
    Einzelpraxen Ärzte
         67.000
    [KBVPraxen2010]
    M7
    Gemeinschaftspraxen Ärzte
         20.000
    [KBVPraxen2010]
    M8
    Medizinische Versorgungszentren (MVZ)
          1.700
    [KBVPraxen2010]
    M9
    Einzelpraxen Zahnärzte
         36.500
    [KZBV2010]
    M10
    Mehrfachpraxen Zahnärzte
          8.400
    [KZBV2010]
    M11
    Praxen Psychotherapeuten
         17.300
    Annahme: M4
    M12
    Krankenhäuser
          2.000
    [DKG2010]
    M13
    Lokationen (Praxen und KH)
        152.900
    M6 + M7 + M8 + M9 + M10 + M11 + M12
    M25
    Apotheken (inkl Filialapotheken)
         20.249
    [ABDA2016]
    M26
    Lokationen (Praxen, KH, Apotheken)
        173.149
    M13 + M25
    M28
    Gesetzliche Krankenkassen
              109
    [GKVKassen2019]

    Tabelle 19: Tab_Mengengerüst: Krankenhäuser (Quelle: [DKG2010])

    Krankenhäuser nach Größenklassen
    ID
    Größenklasse
    KH
    Ärzte
    pro KH
    ltd. Ärzte
    + Oberärzte
    pro KH
    Fälle pro
    Tag u. KH
    ambulant
    Fälle pro
    Tag u. KH
    stationär
    M14
    unter 100 Betten
        646
              8
              3
              5
              5
    M15
    100 bis 199 Betten
        468
             30
             11
             19
             19
    M16
    200 bis 299 Betten
        302
             57
             19
             65
             32
    M17
    300 bis 399 Betten
        204
             85
             29
             95
             47
    M18
    400 bis 599 Betten
        224
            135
             45
            137
             69
    M19
    600 bis 799 Betten
         69
            211
             65
            288
             96
    M20
    800 und mehr Betten
         90
            559
            149
            537
            179

    Tabelle 20: Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen

    Klasse der
    Leistungserbringer-
    umgebung (LE-Ux)
    Großer Repräsentant in der Klasse der LE-Umgebung
    Beschreibung
    Ärzte
    ltd. Ärzte
    + Oberärzte
    Fälle pro Tag
    ambulant
    stationär
    1
    Praxis,
    Gemeinschaftspraxen,
    MVZ, KH "bis 199 Betten"
    Ø KH (144 Betten)
    "100 bis 199 Betten"
       30
       11
         19
         19
    2
    KH "200 bis 599" Betten
    Ø KH (482 Betten)
    "400 bis 599 Betten"
      135
       45
      137
       69
    3
    großes KH
    KH "600 bis 1599 Betten"
    Ø KH (1219 Betten)
    "800 Betten und mehr"
      559
      149
      537
      179
    4
    sehr großes KH
    KH "1600 Betten und mehr"
    3000 Betten
    1.398
      373
    1.343
      448

    Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen" nimmt eine grobe Klassifizierung sämtlicher Leistungserbringerumgebungen in vier Größenklassen vor. Klasse LE-U1 beinhaltet Praxen, Gemeinschaftspraxen, medizinische Versorgungszentren und Krankenhäuser bis 199 Betten3. Klasse LE-U2 umfasst Krankenhäuser bis 599 Betten. Klasse LE-U3 umfasst große Krankenhäuser. Klasse LE-U4 umfasst sehr große Krankenhäuser. Im Hinblick auf Lastanforderungen ist für jede Klasse ein besonders großer Repräsentant ausgewählt. Der Repräsentant der Klasse 4 wurde so groß gewählt, dass er mit Sicherheit größer als die größten existierenden Krankenhäuser ist.

    3) Perspektivisch kann es in späteren Ausrollstufen entsprechend des Lastaufkommens für weitere Anwendungsfälle notwendig werden, die Klasse weiter zu unterteilen. Neben dem Klassenrepräsentanten eines "100 bis 199 Betten"-Krankenhaus wird zusätzlich als Praxisrepräsentant eine Praxis für 1000 Versicherte berücksichtigt. Die jeweils pro Anwendungsfall höheren Spitzenlasten dieser beiden Repräsentanten sind für die Anforderungen maßgeblich.

    Tabelle 21: Tab_Mengengerüst: Annahmen für Modellierung

    ID
    Größe
    Wert
    Quelle
    M21
    Anzahl Konnektoren
        173.149
    Annahme: M26
    M22
    Dauer Modellarbeitstag Praxis
    8 h
    Festlegung
    M23
    Dauer Modellarbeitstag Krankenhaus
    16 h
    Festlegung
    M29
    Dauer Modellarbeitstag Apotheke 10 h
    Festlegung
    M24
    KOM-LE-Teilnehmer
        210.109
    Annahme: M2 + M3 + M4 + M28 

    4.1.2 Versichertenstammdatenmanagement (VSDM)

    Das Versichertenstammdatenmanagement (VSDM) umfasst fünf performance-relevante Anwendungsfälle (siehe [gemKPT_Perf_VSDM]), die eine Kombination der folgenden drei Aktivitäten gemäß Tabelle "Tab_VSDM Anwendungsfälle" sind:

    Tabelle 22: Tab_VSDM Anwendungsfälle

    VSDM Anwendungsfälle
     Prüfung Aktualität
     Aktualisierung
     Lesen VSD
    Lesen VSD mit Online-Prüfung mit Aktualisierung der VSD
    x
    x
    x
    Lesen VSD mit Online-Prüfung ohne Aktualisierung der VSD
    x
     
    x
    Lesen VSD ohne Online-Prüfung
     
     
    x
    Automatische Online-Prüfung mit Aktualisierung der VSD
    x
    x
     
    Automatische Online-Prüfung ohne Aktualisierung der VSD
    x
     
     


    In der folgenden Lastbetrachtung wird vereinfachend davon ausgegangen, dass nur das Online-Szenario genutzt wird, das die Anwendungsfälle 1 und 2 umfasst. Zusätzlich wird angenommen, dass bei jedem „Lesen VSD“ auch eine Prüfung auf Aktualität erfolgt. Diese Vereinfachung in der Betrachtung ist zulässig, weil dadurch die Last allenfalls geringfügig überschätzt wird. Die daraus resultierenden Vorgaben für die Produkttypen sind dann hinreichend, um die die tatsächliche Last abzudecken. Im Lastmodell werden daher nur die ersten beiden Anwendungsfälle aus Tabelle "Tab_VSDM Anwendungsfälle" berücksichtigt.

    4.1.3 Kommunikation Leistungserbringer (KOM-LE)

    Für KOM-LE als sicheres Übermittlungsverfahren (SÜV) werden folgende performance-relevante Anwendungsfälle (siehe [gemSysL_KOM-LE]) betrachtet:

    Die Kommunikation zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst erfolgt über einen sicheren Kanal. Da ein einmal aufgebauter sicherer Kanal zum Senden und Empfangen mehrere Nachrichten verwendet werden kann, wird der Aufbau des sicheren Kanals im Folgenden als separater Anwendungsfall betrachtet.

    Die eventuell notwendige Nachrichtenweiterleitung von dem KOM-LE-Fachdienst des Senders zum KOM-LE-Fachdienst des Empfängers findet asynchron sowohl zum Sende- als auch zum Abholprozess statt und wird daher separat behandelt.

    Hinweis: In der Version KOM-LE 1.0 ist die Nachrichtengröße auf 25 MB begrenzt. Ab KOM-LE 1.5 ist es auch möglich E-Mail-Nachrichten mit Anhängen größer 25MB zu versenden bzw. zu empfangen. Der Mail-Body ohne Anhänge darf aber weiterhin die Größe von 25 MB nicht übersteigen und muss durch das KOM-LE-Clientmodul und den KOM-LE-Fachdienst verarbeitet werden.

    4.1.4 Notfalldaten-Management (NFDM)

    Das Notfalldaten-Management (NFDM) umfasst folgende performance-relevanten Anwendungsfälle (siehe [gemSysL_NFDM]), die vom Primärsystem aufgerufen werden.

    Notfalldaten (NFD) haben eine maximale Größe von 11,5 KB. Die Persönlichen Erklärungen (DPE) haben eine maximale Größe von 1,5 KB.

    4.1.5 eMP/AMTS-Datenmanagement

    Das eMP/AMTS-Datenmanagement umfasst folgende performance-relevanten Anwendungsfälle (siehe [gemSysL_AMTS_A]), die vom Primärsystem aufgerufen werden.

    Die auf der eGK gespeicherten eMP/AMTS-Daten haben auf der eGK eine maximale Größe von 13,56 KB. Im XML-Format haben sie eine Größe von etwa 30 KB.

    4.1.6 Elektronische Patientenakte (ePA)

    Für die elektronische Patientenakte werden die sechs folgenden performance-relevanten Anwendungsfälle aus [gemSysL_ePA] betrachtet:

    Es wird davon ausgegangen, dass beim Aufruf einer Fachoperation implizit der Aufbau einer Aktensession inkl. Login durch einen Leistungserbringer/Versicherten erfolgt. Ebenfalls wird angenommen, dass die Dokumentengröße zwischen 10 KB und 1 MB beträgt. Es wird erwartet, dass es sich bei den 10 KB Dokumenten um NFD/DPE- und eMP- Dokumente handelt. Arzt- und Entlassbriefe werden mit einer Dokumentengröße größer 100 KB geschätzt. Die Dokumentengröße weiterer medizinische Informationsobjekte ist nicht abschätzbar, überschreitet aber auch nicht 1 MB. Die maximale erlaubte Dokumentengröße beträgt 25 MB.

    4.1.7 Tokenbasierte Authentisierung (TBAuth)

    [verschoben in 3.x.1.1 Lastmodell IDP-Dienste]

    4.1.8 Lastmodell auf Ebene der Anwendungsfälle

    Das Lastmodell verknüpft die zu erwartende Anfragerate je Anwendungsfall mit Mengengrößen aus dem Mengengerüst per Proportionalitätsfaktor und nennt die jeweils bearbeiteten Datenmengen.

    Da hier Zahlen zu Annahmen über das Benutzerverhalten einfließen, die grundsätzlich nicht exakt vorhersagbar sind, wird mit Sicherheitsfaktoren gearbeitet (siehe „Spitzenlasterhöhung“ unten).

    Lastmodell: Nutzung bestehender Anwendungen und Netze

    Für die Nutzung bestehender Anwendungen und Netze liegt die Leistung der TI-Plattform auf Netzwerkebene. Tabelle "Tab_Lastmodell: Nutzung bestehender Anwendungen und Netze" gibt die Spitzenlast hierfür an.

    Tabelle 23: Tab_Lastmodell: Nutzung bestehender Anwendungen und Netze

    Spitzenlast in MBit/sec
    (jeweils down- und upload-Richtung)
    150

    Lastmodell: VSDM-Anwendungsfälle und die davon unabhängige Nutzung der Basisdienste

    Für VSDM und die davon unabhängige Nutzung der Basisdienste QES, digitale Signatur und Verschlüsselung wird die Spitzenlast auf Ebene der Anwendungsfallaufrufe durch die folgenden vier Tabellen definiert.

    Tabelle "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" basiert auf den Zahlen der Lastmodellierung aus [gemSpec_Intermediär_VSDM]. In die angegebene Spitzenlast fließen die Zahl der Online-Prüfungen pro Quartal, die Anzahl der Versicherten und die Modellannahme einer Häufung der Online-Abfragen in der ersten Quartalswoche ein. Die angegebenen Datenmengen ergeben sich aus den pro Anwendungsfall summierten http-Nachrichtengrößen (d.h. http-body gemäß [gemSpec_Intermediär_VSDM] zuzüglich 200 Byte http-header).

    Die Spalten „Spitzenlasterhöhung“ in den folgenden Tabellen geben an, um welchen Faktor die Spitzenlast pro Stunde gegenüber der Gleichverteilung der „Spitzenlast pro Tag“ über den Arbeitstag erhöht ist, wobei die Dauer des Arbeitstags ohne Beeinträchtigung der Allgemeinheit für die Modellbetrachtung in Tabelle "Tab_Mengengerüst: Annahmen für Modellierung" festgelegt wird. Für das Krankenhaus motiviert sich die Spitzenlasterhöhung beispielsweise bei den VSDM-Anwendungsfällen stationär dadurch, dass zwischen 9 und 14 Uhr etwa 70 % der Patienten aufgenommen werden. Um solche bekannten, aber auch unbekannte systematische Erhöhungen gegenüber der Gleichverteilung der „Spitzenlast pro Tag“ über den Arbeitstag abzudecken, ist je Anwendungsfall ein Faktor angegeben, der sich aus der Häufigkeit des Anwendungsfalles ergibt. Damit hat der Faktor zugleich die Qualität eines Sicherheitsfaktors.

    Zur Erläuterung des Faktors „Spitzenlasterhöhung“ wird an Hand von Tabelle "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" exemplarisch die Spitzenlast pro Tag für 1000 Versicherte für den Anwendungsfall „VSD Lesen mit Aktualisierungsprüfung ohne Update“ sowie die Spitzenlast pro Stunde berechnet, in die der „Spitzenlasterhöhungsfaktor“ einfließt:

    Spitzenlast pro Tag = 0,10 * 1000 pro Tag = 100 pro Tag

    Spitzenlast pro Stunde = 100 pro Tag / 8 Stunden pro Tag * 4 = 50 pro Stunde

    Tabelle 24: Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs


    Anwendungsfall

    Datenmenge
    pro Nachricht
    in kByte

    Mengengröße x

    Spitzenlasten
    pro Tag

    Spitzenlast- erhöhungs-
    faktor
     VSD Lesen mit  Aktualisierungsprüfung
    ohne Update
    up: 0,7
    down: 0,9
    Anzahl
    Versicherte
    0,10 * x
    4
     VSD Lesen mit  Aktualisierungsprüfung
     mit Update
    up: 4,3
    down: 21,7
    Anzahl
    Versicherte
    0,0025 * x
    4

    Bei der Verteilung der Spitzenlasten aus Tabelle "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" auf die einzelnen Praxen und MVZs wird von einer Gleichverteilung der Versicherten auf alle Leistungserbringer und einer Verteilung der Leistungserbringer auf Praxen und MVZs gemäß Tabelle "Tab_Mengengerüst: Lokationen" ausgegangen.

    Tabelle 25: Tab_Lastmodell der Basisdienste QES für Leistungserbringer (LE) Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

    Anwendungsfall
    Datenmenge
    pro Anwendungsfall
    in kByte
    Mengengröße
    x
    Spitzenlasten
    pro Tag
    Spitzenlast- erhöhungs-
    faktor

    QES: Arztsignaturen erstellen
    (HBA)
    50
    Anzahl LE
    5 * x
    2

    100
    25 * x
    4

    25600
    x
    2

    QES: Arztsignaturen prüfen
    (HBA)
    50
    5 * x
    2

    100
    25 * x
    4

    25600
    x
    2

    Digitale Signaturen erstellen
    (SMC-B)
    50
    0,5 * x
    2

    100
    11 * x
    4

    25600
    0,05 * x
    2

    Digitale Signaturen prüfen
    (SMC-B)
    50
    0,5 * x
    2

    100
    11 * x
    4

    25600
    0,05 * x
    2

    Daten verschlüsseln
    (SMC-B, HBA)
    50
    0,5 * x
    2

    100
    11 * x
    4

    25600
    0,05 * x
    2

    Daten entschlüsseln
    (SMC-B, HBA)
    50
    0,5 * x
    2

    100
    11 * x
    4

    25600
    0,05 * x
    2

    Authentisierung (SMC-B: C.HCI.AUT, HBA: C.HP.AUT)
     
    2 * x
    4

    Tabelle 26: Tab_Lastmodell der Basisdienste QES in Krankenhäuser mit stationären Fällen

    Anwendungsfall
    Datenmenge
    pro Anwendungs-fall
    in kByte
    Mengengröße x
    Spitzenlasten
    pro Tag
    Spitzenlast- erhöhungs-
    faktor

    QES: Arztsignaturen erstellen
    (HBA)

    50
    x: stationäre Fälle im KH pro Tag
    0,5 * x
    2

    100
    1,3 * x
    4

    25600
    0,06 * x
    2

    QES: Arztsignaturen prüfen
    (HBA)

    50
    0,5 * x
    2

    100
    1,3 * x
    4

    25600
    0,06 * x
    2

    Digitale Signaturen erstellen
    (SMC-B)

    50
    0,04 * x
    2

    100
    0,1 * x
    4

    25600
    0,005 * x
    2

    Digitale Signaturen prüfen
    (SMC-B)

    50
    0,04 * x
    2

    100
    0,1 * x
    4

    25600
    0,005 * x
    2

    Daten verschlüsseln
    (SMC-B, HBA)

    50
    0,04 * x
    2

    100
    0,1 * x
    4

    25600
    0,005 * x
    2

    Daten entschlüsseln
    (SMC-B, HBA)

    50
    0,04 * x
    2

    100
    0,1 * x
    4

    25600
    0,005 * x
    2

    Authentisierung
    (SMC-B: C.HCI.AUT, HBA: C.HP.AUT)

     
    0,1 * x
    4



    Die Mengengrößen in „Mengengröße x“ in Tabelle "Tab_Lastmodell der Basisdienste QES für Leistungserbringer (LE) Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" und Tabelle "Tab_Lastmodell der Basisdienste QES in Krankenhäuser mit stationären Fällen" verknüpfen die Anfrageraten (Spitzenlasten) mit den Mengengrößen aus Tabelle "Tab_Mengengerüst: Versicherte und Leistungserbringer".

    Tabelle 27: Tab_Lastmodell: Krankenhäuser (Quelle: [DKG2010])

    Anwendungsfall
    Datenmenge
    pro
    Anwendungs-
    fall
    in kByte
    Mengengrößen
    x und y
    Spitzenlasten
    pro Tag
    Spitzenlast-
    erhöhungs-
    faktor
    VSD Lesen mit
    Aktualisierungsprüfung ambulant (*)
    (*)
    x =
    stationäre
    Fälle
    pro Tag

    y =
    ambulante
    Fälle
    pro Tag
    1 * y
    4
    VSD Lesen mit
    Aktualisierungsprüfung stationär (*)
    (*)
    1 * x
    4
     QES: Arztsignaturen erstellen  (HBA) (**)
    100
    3,25 * x + 0,25 y
    4
    QES: Arztsignaturen prüfen
    (HBA)
    100
    0,5 * x + 0,25 * y
    4
    Digitale Signaturen erstellen
    (SMC-B)
    100
    1,25 * x
    4
    Digitale Signaturen prüfen
    (SMC-B)
    100
    1,25 * x
    4
    Daten verschlüsseln
    (SMC-B, HBA)
    100
    1,25 * x
    4
    Daten entschlüsseln
    (SMC-B, HBA)
    100
    1,25 * x
    4


    (*) Es sind zwei Situationen zu unterscheiden: In 2,5 % der Anwendungsfälle erfolgt ein Update und in 97,5 % der Anwendungsfälle erfolgt kein Update, wobei sich die prozentuale Aufteilung und die Nachrichtengrößen aus Tabelle "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" ergeben.

    (**) Bei der QES wird für die Stapelgrößen angenommen, dass 75 % der Anwendungsfälle Stapelgröße 1 und 25 % die Stapelgröße 2 haben.

    Die Mengengrößen in „Mengengrößen x und y“ in Tabelle "Tab_Lastmodell: Krankenhäuser" verknüpfen die Anfrageraten (Spitzenlasten) mit den Mengengrößen aus Tabelle "Tab_Mengengerüst: Krankenhäuser" und Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen".

    Lastmodell: KOM-LE-Anwendungsfälle

    Die erwartete Nutzungsrate der KOM-LE-Anwendungsfälle wird in Tabelle "Tab_Lastmodell KOM-LE-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs beschrieben sowie in Tabelle "Lastmodell: KOM-LE in Krankenhäusern" für die Ärzte in den Krankenhäusern. Die angegebenen Spitzenlasten skalieren jeweils mit Anzahl der KOM-LE-Teilnehmer oder der Zahl der stationären Fälle im KH pro Tag.

    Zwei besondere Lastsituationen sind ergänzend zur Durchschnittsbetrachtung berücksichtigt:

    Tabelle 28: Tab_Lastmodell KOM-LE-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

    Anwendungsfall
    Datenmenge
    pro Anwendungs-
    fall in KByte
    Mengen-
    größe x
    Spitzenlasten pro Tag
    Spitzenlast- erhöhungs-faktor

    Empfängerdaten ermitteln
    10
    x: Anzahl KOM-LE
    Teilnehmer
    20 * x
    2

    Nachricht schützen und
    an KOM-LE-Fachdienst senden

    50
    8 * x
    2

    100
    20 * x
    2

    25600
    1 * x
    1

    Nachricht vom KOM-LE Fachdienst holen und aufbereiten
    50
    8 * x
    2

    100
    20 * x
    2

    25600
    1 * x
    1

    Aufbau sicherer Kanal vom Clientmodul zum Fachdienst
     
    68 * x
    2



    Teilnehmer pflegt seine Basisdaten
     
    0,004 * x
    2

    Nachrichtenweiterleitung zwischen KOM-LE-Fden
    50
    8 * x
    2

    100
    20 x *
    2

    25600
    2 * x
    2

    Tabelle 29: Tab_Lastmodell: KOM-LE in Krankenhäusern

    Anwendungsfall
    Datenmenge
    pro Anwendungs-fall in KByte
    Mengen-größe x
    Spitzenlasten pro Tag
    Spitzenlast- erhöhungs-faktor
    Empfängerdaten ermitteln
    10
    x: stationäre Fälle
    im KH pro Tag
    2 * x
    4
    Nachricht schützen und an KOM-LE-Fachdienst senden
    50
    0,8 * x
    2
    100
    2 * x
    4
    25600
    0,1 * x
    2
    Nachricht vom KOM-LE Fachdienst holen und aufbereiten
    50
    0,8 * x
    2
    100
    2 * x
    4
    25600
    0,1 * x
    2
    Aufbau sicherer Kanal vom Clientmodul zum Fachdienst
     
    x: Anzahl KOM-LE-Fachdienste
     *  Anzahl KOM-LE-Client-Module
    2 * x
    4
    Nachrichtenweiterleitung zwischen KOM-LE-Fden
    50
    x: Anzahl
    KOM-LE
    Teilnehmer
    8 * x
    1
    100
    20 * x
    1
    25600
    1 * x
    1


    Annahme: KOM-LE-Teilnehmer in Krankenhausumgebung sind die in Tabelle "Tab_Mengengerüst: Krankenhäuser" und Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen" aufgeführten „Ärzte“.

    Die erwartete Nutzungsrate der KOM-LE-Anwendungsfälle für Nachrichten mit Anhängen größer 25 MB ist in Tabelle "Tab_Lastmodell: KOM-LE-Anwendungsfälle für große Nachrichten" dargestellt.

    Tabelle 30: Tab_Lastmodell: KOM-LE-Anwendungsfälle für große Nachrichten

    Anwendungsfall
    Mengengröße x
    Spitzenlasten pro Tag
    Spitzenlast- erhöhungs-faktor
    Abrechnungsdaten übermitteln
    x: Anzahl KOM-LE
    Teilnehmer
    1 * x
    2
    Abrechnungsdaten empfangen
    1 * x
    2
    Bilder oder andere Aufnahmen zur Diagnostik senden
    0,15 * x
    2
    Bilder oder andere Aufnahmen zur Diagnostik empfangen
    0,45 * x
    2
    Sonstige Große Anhänge in Mail
    senden

    0,25 * x
    2
    Sonstige Große Anhänge in Mail
    empfangen

    0,50 * x
    2
    Herausgabe von Patientendaten
    x: Anzahl d. Versicherten
    0,12 * x
    -

    In der Lastbetrachtung wird davon ausgegangen, dass für den Anwendungsfall: "Bilder oder andere Aufnahmen zur Diagnostik empfangen" es je Sender 3 Empfänger gibt. Für den Anwendungsfall: "Sonstige Große Anhänge in Mail empfangen" wird angenommen, dass es je Sender 2 Empfänger gibt.

    Lastmodell: NFDM-Anwendungsfälle

    Die erwartete Nutzungsrate der NFDM-Anwendungsfälle wird in Tabelle "Tab_Lastmodell NFDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs beschrieben sowie inkludiert in Tabelle "Tab_Lastmodell: Krankenhäuser" für die Ärzte in den Krankenhäusern. Die angegebenen Spitzenlasten skalieren jeweils mit Anzahl der Ärzte oder der Zahl der ambulanten und stationären Fälle im KH pro Tag.

    Dabei ergibt sich der Lastbeitrag für die Krankenhäuser zu Tabelle "Tab_Lastmodell: Krankenhäuser" wie folgt: Für das Prüfen der qualifizierten Arztsignatur wird für Prüfung der Signatur im Kontext Notfalldaten ein Faktor 0,25 (ambulant und stationär) und für Prüfung der Signatur beim Austausch von signierten Dokumenten zwischen den Krankenhäusern ein weiterer Faktor 0,25 (stationär) angesetzt.

    Tabelle 31: Tab_Lastmodell NFDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

    Titel
    Datenmenge pro
    Anwendungsfall
    in KByte
    Mengengrößen
    Spitzenlast pro Tag
    Spitzenlast-
    erhöhungsfaktor
    NFD signieren
    10,5
    x: Anzahl LE
    6,1 * x
    1
    NFD schreiben
    10,5
    6,1 * x
    1
    NFD lesen
    10,5
    3,3 * x
    1
    NFD löschen
    10,5
    0,6 * x
    1
    DPE schreiben
    1,5
    0,6 * x
    1
    DPE lesen
    1,5
    0,4 * x
    1
    DPE löschen
    1,5
    0,1 * x
    1

    Lastmodell: Für eMP/AMTS-Anwendungsfälle

    Die erwartete Nutzungsrate der eMP/AMTS-Anwendungsfälle wird in Tabelle "Tab_Lastmodell eMP/AMTS-Anwendungsfälle in Praxen und Apotheken" für Praxen (Mengengröße M13) und Apotheken (Mengengröße M25) beschrieben. In einzelnen Apotheken müssen parallel an 10 Arbeitsplätzen für jeweils verschiedene eGKs die Vorgänge „eMP/AMTS-Daten von eGK lesen und dann schreiben“ ausgeführt werden können.

    Tabelle 32: Tab_Lastmodell eMP/AMTS-Anwendungsfälle in Praxen und Apotheken

    Titel
    Datenmenge
    auf eGK
    [KB]
    Typ der LE-Umgebung
    durchschnittliche Aufrufanzahl
    pro Tag
    pro Lokation
    Spitzenlast-
    erhöhungsfaktor
    eMP/AMTS-Daten von eGK lesen
    13,6
    Praxen
    4
    4
    Apotheken
    30
    4
    eMP/AMTS-Daten auf eGK schreiben
    13,6
    Praxen
    4
    4
    Apotheken
    30
    4

    Hinweis: G(iga), M(ega), K(ilo) bezeichnet hier G=(1024)3, M=(1024)2 und K=(1024)1.

    Lastmodell: Für ePA-Anwendungsfälle

    Die Tabelle "Tab_Lastmodell ePA aus der LE-U für Praxen, Apotheken und Krankenhäuser" stellt eine Übersicht über die zu erwartenden Nutzungsraten für ePA dar.

    Tabelle 33: Tab_Lastmodell ePA aus der LE-U für Praxen, Apotheken und Krankenhäuser

    LEI
    Mengengröße
    Dokument-
    Typ
    Datenmenge
    [KB]
    Erwartete
     Anzahl an Anwendungsfälle pro Tag je LEI


    Praxis
    M6 + M7 + M8 + M9 + M10  + M11
    eMP
    10
    5

    NFD/DPE
    10
    1

    Arztbrief
    1000
    5

    Sonstige
    1000
    2

    Apotheke
    M25
    eMP
    10
    25

    Krankenhaus
    M12
    eMP
    10
    10

    NFD/DPE
    10
    5

    Entlassbrief
    1000
    (*)

    Sonstige
    1000
    3

    Die Mengengröße der ePA-Teilnehmer bezieht sich auf die Tabelle "Tab_Mengengerüst: Lokationen". Unter der erwarteten Anzahl an Anwendungsfällen pro Tag je LEI wird zum Beispiel das Einstellen eines Arztbriefes verstanden. In der Modellbetrachtung ist für die Anzahl der Anwendungsfälle pro Tag ein Sicherheitsfaktor von 2 mit eingerechnet.

    In Praxen und Krankenhäusern wird erwartet, dass die verwendeten Dokumenttypen eMP, NFD/DPE, Arzt- und Entlassbriefe in ePA Anwendung finden. In den Apotheken wird davon ausgegangen, dass ausschließlich ePA-Anwendungsfälle mit dem Medikationsplan erfolgen.

    Gemäß Kapitel 3.1.6 wird davon ausgegangen, dass die durchschnittliche Dokumentgröße der Dokumenttypen eMP und NFD/DPE 10 KB beträgt. Arzt- und Entlassbriefe werden mit einer durchschnittlichen Dokumentgröße von 1 MB angenommen.

    (*) Die Anzahl der im Krankenhaus ausgestellten Entlassbriefe ist abhängig von der Anzahl der stationären Fälle pro Tag und somit von der Größe der Leistungserbringer-Umgebung (LE-U) gemäß Tabelle "Klassen der Leistungserbringer(LE)-Umgebungen".

    Zusätzlich wird vermutet, dass jeder gesetzlich Versicherte (70 Mio.) einmal im Jahr bei seiner gesetzlichen Krankenkasse eine Versichertenauskunft (Auskünfte an Versicherte) beantragt.

    In Tabelle "Tab_ePA-Anwendungsfälle je LE-U" wird die erwartete Anzahl an ePA-Anwendungsfälle pro Tag je Leistungserbringer-Umgebung dargestellt.

    Tabelle 34: Tab_ePA-Anwendungsfälle je LE-U


    ePA - Anwendungsfälle
    Klasse der
    LE-Umgebung
    eMP-Fälle
    pro Tag
    NFD/DPE-Fälle
    pro Tag
    Arztbriefe
    pro Tag
    Entlass-
    briefe
    pro Tag
    Sonstige Dokumente
    pro Tag
    LE-U1
    5
    1
    5
    19
    2
    LE-U2
    10
    5
    -
    74
    4
    LE-U3
    35
    17
    -
    184
    7
    LE-U4
    87
    43
    -
    453
    17

    Es sind in LE-U1 fünf Arztbriefe und 19 Entlassbriefe mit eingerechnet, da LE-U1 gemäß Tabelle "Klassen der Leistungserbringer(LE)-Umgebungen" Praxen, Gemeinschaftspraxen, MVS und KH klassifiziert.

    Die Anzahl der Entlassbriefe pro Tag für die LE-U2 – LE-U4 ergeben sich aus der Anzahl der stationären Fälle pro Tag addiert mit den fünf Arztbriefen aus LE-U1. Somit werden neben Entlassbriefen auch Arztbriefe in den jeweiligen LE-U mit berücksichtigt.

    Die zu erwartete Nutzungsrate aus der Versicherten-Umgebung wird in Tabelle "Tab_Lastmodell ePA aus der Versicherten-Umgebung" dargestellt.

    Tabelle 35: Tab_Lastmodell ePA aus der Versicherten-Umgebung

    gesetzlich
    Versicherte
    Anzahl ePA Teilnehmer in %
    Anzahl Versicherte
    Anzahl Dokumente pro Jahr je Versicherter
    70 Mio.
    50
    35 Mio.
    17

    Hierbei wird davon ausgegangen, dass im Maximalausbau etwa 35 Mio. gesetztlich Krankenversicherte die Fachanwendung ePA von der Versicherten-Umgebung nutzen werden. Es wird je Versicherter eine Anzahl  von 17 Dokumenten pro Jahr erwartet.

    Es wird geschätzt, dass je Akte pro Versicherter ein Speicherbedarf von a. 300 MB pro Jahr notwendig ist.

    4.1.9 Betriebliche Anwendungsfälle

    Betrieblicher Anwendungsfall: Update des Konnektors bzw. der Kartenterminals

    Beim Ausrollen von Software auf Konnektor und Kartenterminals müssen durch Download vom Konfigurationsdienst Softwarepakete auf die Konnektoren verteilt werden. Tabelle "Tab_Mengenrahmen „Update Konnektor und Kartenterminals“" listet die Annahmen, die für den Mengenrahmen dieses betrieblichen Anwendungsfalls getroffen werden.

    Tabelle 36: Tab_Mengenrahmen „Update Konnektor und Kartenterminals“

    Größe
    Wert
    Quelle
    Zeitraum, in dem ein Softwarepaket vom Konfigurationsdienst über den Download-Weg an sämtliche Konnektoren verteilt werden können muss.
    5 * 24 h
    Betriebliche Anforderung
    maximale Größe eines Softwarepakets
    1500 Mbyte
    Konnektorhersteller

    4.2 Bearbeitungszeiten

    Der anwendungsfallübergreifende Bedarf für die Bearbeitungszeiten an den Außenschnittstellen der TI-Plattform wurde für den Erwartungswert pro Schnittstellenoperation abgestimmt.

    Die Abstimmung erfolgte zweistufig, um Machbarkeit/Wirtschaftlichkeit und Bedarf in Einklang zu bringen. Im ersten Schritt wurden per Expertenschätzung die Leistungswerte für eine wirtschaftlich günstige Lösung bestimmt. Im zweiten Schritt wurde geprüft, ob mit diesen Leistungswerten der Bedarf der Fachanwendungen erfüllt werden kann.

    Für den Produkttyp Konnektor kommen Bearbeitungszeiten durch das Fachmodul hinzu [gemSpec_FM_VSDM].

    Für die Transportnetzanbindung über den Konnektor an Zentrale Dienste der TI-Plattform und Fachanwendungsspezifische Dienste setzt das Performance-Modell typische Bandbreiten an, die dann in Anforderungen zu Bearbeitungszeiten einfließen: Für Praxen einen asymmetrischen Zugang von 1024 kbit/sec in Download-Richtung und 128 kbit/sec in Upload-Richtung (mit Round-Trip-Time von 50 msec) für Krankenhäuser einen symmetrischen Zugang von 2048 kbit/sec in Upload- und Download-Richtung (mit Round-Trip-Time von 40 msec).

    4.2.1 Bearbeitungszeiten KOM-LE

    Für KOM-LE müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_Bearbeitungszeitvorgaben KOM-LE je Anwendungsfall" angegebenen Mittelwerten sein.

    Tabelle 37: Tab_Bearbeitungszeitvorgaben KOM-LE je Anwendungsfall

    Anwendungsfall
    Datenmenge
    [KB]
    Mittelwert
    [sec]
    Empfängerdaten ermitteln
    1
    1,2
    Nachricht schützen und an KOM-LE-Fachdienst senden
    100
    12,5
    25.600
    260
    Nachricht vom KOM-LE Fachdienst holen und aufbereiten
    100
    4,7
    25.600
    38,5
    Aufbau sicherer Kanal vom Clientmodul zum Fachdienst
    (*)
    3,9
    Nachrichtenweiterleitung zwischen KOM-LE-Fachdiensten
    (*)
    (**)


    (*) nicht relevant für die Bearbeitungszeit

    (**) Nachrichten müssen spätestens 10 Minuten nach dem erfolgreichen Versenden zum Abruf für den Empfänger bereitstehen.

    4.2.2 Bearbeitungszeiten Notfalldaten-Management (NFDM)

    Für NFDM müssen im stationären Einsatz unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_Bearbeitungszeitvorgaben NFDM je Anwendungsfall" angegebenen Mittelwertschranken sein.

    Tabelle 38: Tab_Bearbeitungszeitvorgaben NFDM je Anwendungsfall

    Anwendungsfall
    Datenmenge
    [KB]
    Mittelwert
    [sec]
    NFD signieren (QES)
    10,5
    1,8
    NFD schreiben
    10,5
    5,8
    NFD lesen
    10,5
    7,3
    NFD löschen
    10,5
    4,8
    DPE schreiben
    1,5
    4,6
    DPE lesen
    1,5
    4,3
    DPE löschen
    1,5
    4,3


    Für die Einsätze im mobilen Bereich sollen diese Vorgaben ebenfalls erreicht werden. Priorität hat der Anwendungsfall „NFD lesen“.

    4.2.3 Bearbeitungszeiten eMP/AMTS-Datenmanagement

    Für eMP/AMTS müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_Bearbeitungszeitvorgaben eMP/AMTS je Anwendungsfall" angegebenen Mittelwertschranken sein.

    Tabelle 39: Tab_Bearbeitungszeitvorgaben eMP/AMTS je Anwendungsfall

    Anwendungsfall
    Datenmenge
    [KB]
    Mittelwert
    [sec]
    eMP/AMTS-Daten von eGK lesen
    13,56
    5,3
    eMP/AMTS-Daten auf eGK schreiben
    13,56
    6,7

    4.2.4 Bearbeitungszeiten elektronische Patientenakte (ePA)

    Für ePA müssen unter den oben genannten Rahmenbedingungen der Mittelwerte der Bearbeitungszeit pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_ePA Bearbeitungszeitvorgaben je Anwendungsfall" angegebenen Mittelwertschranken sein.

    Es werden nur die Anwendungsfälle betrachtet, die häufig in der LE-Umgebung Anwendung finden.

    Tabelle 40: Tab_ePA Bearbeitungszeitvorgaben je Anwendungsfall

    Anwendungsfall
    Datenmenge
    [KB]
    Mittelwert
    [sec]
    Login des Versicherten in der LEI
    (*)
    9,5
    Dokument in der LEI suchen
    3
    1,2
    Dokument in der LEI löschen
    2
    1,1
    Dokument in der LEI anzeigen
    10
    1,2
    100
    2,0
    1000
    10,5
    25600 (**)
    30,0
    Dokument in der LEI einstellen
    10
    1,8
    100
    8,3
    1000
    73,2
    25600 (**)
    240,0

    (*) nicht relevant für die Bearbeitungszeit

    (**) Für das Anzeigen und Einstellen von 25 MB-Dokumenten in der LEI-Umgebung wird von einer Transportanbindung von 16 Mbit/s in Download-Richtung und 1024 Kbit/s in Upload-Richtung ausgegangen. 

    Es wird bei den Anwendungsfällen "Dokument in der LEI suchen, löschen, anzeigen und einstellen" davon ausgegangen, dass ein Login bereits durchgeführt wurde. Sofern kein Login durchgeführt wurde, muss die Bearbeitungszeit für die Durchführung eines Logins mit berücksichtigt werden.

    4.2.5 Bearbeitungszeiten Tokenbasierte Authentisierung

    [verschoben in 3.x.1.2 Bearbeitungszeiten IDP-Dienste]

    4.3 Verfügbarkeiten

    Die zu fordernde Verfügbarkeit richtet sich am Bedarf der Anwendungsfälle aus. Der höchste Bedarf entsteht in großen Krankenhäusern. Prinzipiell begrenzendes Element für die Verfügbarkeit ist das Transportnetz. Einzelne Krankenhäuser können sich für das obere Ende der am Markt erhältlichen Verfügbarkeit entscheiden, die mit 99,5 % angenommen wird. Es wird weiter angenommen, dass diese großen Krankenhäuser in der Lage sind, die Verfügbarkeit für Clientsystem und Konnektor mit Kartenterminals auf jeweils 99,9 % zu halten. Ist die Verfügbarkeit des Backend etwa genau so groß wie der für große Krankenhauseinrichtungen mögliche Beitrag von 99,3 %, dann wird ein ausgewogener Wert erreicht.

    Tabelle "Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus" zeigt die so für den Anwendungsfall „VSD Lesen mit Aktualisierungsprüfung ohne Update“ erzielbare Gesamtverfügbarkeit von 98,5 %, die einer Ausfallzeit pro Monat von kleiner 7 Stunden entspricht. Sie ist notwendig und tragbar.

    Tabelle 41: Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus

    Anwendungsfall bzw. Produkttyp
    Verfügbarkeit
    Ausfallzeiten pro Monat in Stunden
    VSD Lesen mit Aktualisierungsprüfung ohne Update
    98,5%
    < 7
     
    Clientsystem
    99,9%
    < 0,5
     
    Konnektor und eHealth-Kartenterminal
    99,9%
    < 0,5
     
    Transportnetz
    99,5%
    < 2,5
     
    Zentrale TI-Plattform: VPN-Zugangsdienst
    99,9%
    < 0,5
     
    Zentrale TI-Plattform: OCSP-Responder
    99,9%
    < 0,5
     
    Zentrale TI-Plattform: Zentrales Netz TI
    99,9%
    < 0,5
     
    Zentrale TI-Plattform: Namensdienst
    99,9%
    < 0,5
     
    VSDM Intermediär
    99,8%
    < 1
     
    Fachdienst VSDM (UFS)
    99,8%
    < 1

    Für die Produkttypen der dezentralen Zone wird erwartet, dass sie selten ausfallen und in diesen seltenen Fällen rasch austauschbar sind. So wird erwartet [DKG2010], dass ein Konnektor, der im Krankenhaus eingesetzt wird, innerhalb von 15 Minuten ausgetauscht werden kann.

    Die Tabelle "Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus im Kontext von E-Rezept" zeigt beispielhaft für den Anwendungsfall „E-Rezept einstellen“ eine erzielbare Gesamtverfügbarkeit von 99,90 %, die einer Ausfallzeit pro Monat von kleiner 7 Minuten entspricht.

    Tabelle 42: Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus im Kontext von E-Rezept

    Anwendungsfall bzw. Produkttyp
    Verfügbarkeit
    Ausfallzeiten pro Monat in Minuten
    E-Rezept einstellen
    99,90%
    < 7
     
    Clientsystem
    99,99%
    < 1
     
    Konnektor und eHealth-Kartenterminal
    99,99%
    < 1
     
    Transportnetz
    99,98%
    < 1
     
    Zentrale TI-Plattform: VPN-Zugangsdienst
    99,99%
    < 1
     
    Zentrale TI-Plattform: OCSP-Responder
    99,99%
    < 1
     
    Zentrale TI-Plattform: Zentrales Netz TI
    99,99%
    < 1
     
    Zentrale TI-Plattform: Namensdienst
    99,99%
    < 1
     
    E-Rezept-Fachdienst
    99,99%
    < 1
     
    IdP
    99,99%
    < 1

    5 Leistungsanforderungen an die Produkttypen der TI

    Das vorliegende Kapitel definiert die Leistungsanforderungen bzgl. der drei Performance-Dimensionen Durchsatz, Bearbeitungszeit und Verfügbarkeit für Produkttypen der TI. Die Anforderungen ergeben sich aus den in Kapitel 3 formulierten Bedarfen.

    Grundlagen für die Performance-Vorgaben sind


    4) Im Rahmen der Produkttypspezifikationen werden die konzeptionellen Schnittstellen aus [gemKPT_Arch_TIP] durch technische Schnittstellen umgesetzt. Die Zuordnung der technischen auf die konzeptionellen Schnittstellen erfolgt in den Produkttypspezifikationen.

    Tabelle 43: Tab_Caching-Dauer

    ID
    Größe
    Dauer
    Quelle
    C1
    OCSP-Caching-Dauer (non QES)
    12 h
    Annahme
    C2
    OCSP-Caching-Dauer (QES)
    6 h
    Annahme
    C3
    DNS-Caching-Dauer
    (Dienstlokalisierung und Namensauslösung)
    12 h
    Annahme

    Alle Spitzenlastvorgaben beziehen sich auf den Produktivbetrieb mit 70 Mio. Versicherten.

    Die Spitzenlastvorgaben für einen Produkttypen beziehen sich, soweit nicht explizit anders angegeben, auf alle Produktinstanzen des Produkttypen in Summe.


    Bearbeitungszeitvorgaben unter Last

    Aus Bedarfssicht sollen alle Produkttypen die Vorgaben für Bearbeitungszeiten unabhängig von den Vorgaben für ihr Lastverhalten erfüllen. D.h. dass die Bearbeitungszeitvorgaben letztlich unter Volllast erfüllt werden sollen.

    Um die Überprüfbarkeit der Anforderungen beherrschbar zu halten, wird dieser Zusammenhang systematisch betrachtet und unter Beachtung der Bedarfssicht vereinfacht. Abbildung 5 unterscheidet hierzu vier Typen von Anforderungen danach, wie sehr die Anforderungen bzgl. Bearbeitungszeit und Lastverhalten ineinandergreifen.


    Abbildung 5: Quadranten der Kombination aus Bearbeitungszeit- und Lastanforderungen


    Im einfachsten Fall (Quadrant 1) werden keine Anforderungen an Bearbeitungszeit und Lastverhalten gestellt, weil kein besonderer Überprüfungsbedarf jenseits funktionaler Tests besteht, etwa für Administrationsfunktionen, die weder mit einer nennenswerten Last ausgeführt werden noch notwendigerweise Bearbeitungszeitvorgaben einhalten müssen.

    Im Quadrant 2 sind Anforderungen gruppiert, die dafür sorgen, dass die Produkttypen den benötigten Durchsatz (z. B. [GS-A_4161]) erreichen. Das betrifft ausschließlich Produkttypen der zentralen Zone der TI-Plattform.

    Im Quadrant 3 sind Anforderungen gruppiert, die für jede Schnittstellen-Operation eines Produkttypen die lastfreie Einhaltung der Bearbeitungszeitvorgaben fordern (z. B. [GS-A_4346]).

    Im Quadrant 4 sind schließlich Anforderungen gruppiert, welche die Einhaltung von Bearbeitungszeitvorgaben unter Last verlangen (z. B. [GS-A_4157], [GS-A_4159], [GS-A_4162] für Produkttypen der zentralen Zone der TI-Plattform).

    5.1 Produkttypen der dezentralen Zone der TI-Plattform

    An die Produkttypen der dezentralen Zone werden keine expliziten Verfügbarkeitsanforderungen gestellt5.

    5) Ausnahme Konnektor für Krankenhäuser.

    5.1.1 Produkttypen eGK, HBA, SMC-B, SMC-K, SMC-KT

    Performance-Anforderungen an die Smartcards im Gesundheitswesen werden im Rahmen der Kartenspezifikationen gestellt.

    5.1.2 Produkttyp Konnektor

    Der Produkttyp Konnektor muss alle Einsatzumgebungen von einer Arztpraxis bis zu großen Krankenhäusern abdecken. Diese unterteilt Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebung" in vier Klassen von Leistungserbringerumgebungen (LE-U1, LE-U2, LE-U3, LE-U4). Über das Lastmodell aus Kapitel 3.1.8 erhält man je Leistungserbringerumgebung die für jede Schnittstellenoperation des Konnektors zu erwartende Spitzenlast.

    Tabelle "Tab_gemSpec_Perf_Konnektor" listet je Schnittstellenoperation zu den Spitzenlastvorgaben die Vorgabenwerte für Bearbeitungszeiten. Die Bearbeitungszeiten beinhalten die an den Kartenterminals und Karten anfallenden Zeiten, was der Steuerungsverantwortung des Konnektors Rechnung trägt.

    Die im Folgenden formulierten Anforderungen sind so angelegt, dass sie die Vorgabenwerte möglichst gut erfüllen, aber auch die Machbarkeitsgrenzen berücksichtigen, die etwa beim konkurrierenden Zugriff des Konnektors auf eine SMC-B bestehen.

    Tabelle 44: Tab_gemSpec_Perf_Konnektor – Last- und Bearbeitungszeitvorgaben

    Schnittstellenoperationen
    Last
    Bearbeitungszeit
    L
    E
    -U
    Spitzen-
    lasten
    [1/h]
    Größe der Anfrage-nachricht
    [kByte]
    Mittelwert
    [msec]
    Fachanwendung
     
     
     
     
     
    I_VSD_Service
     
     
    ReadVSD - mit Akt.-Prüfung, mit Update
    1
    1
     
    6130
     
     
    2
    1
     
     
    3
    4
     
     
    4
    11
     
     
    ReadVSD - mit Akt.-Prüfung, ohne Update
    1
    50
     
    3940
     
     
    2
    50
     
     
     
    3
    175
     
     
     
    4
    437
     
     
     
    ReadVSD - ohne Akt.-Prüfung
     
     
     
    3820
     
     
    UpdateVSD - automat. Akt.-Prüfung, mit Update
     
     
     
    5720
     
     
    UpdateVSD - automat. Akt.-Prüfung, ohne Update
     
     
     
    3130
     
    I_NFD_Management
     
     
    NFD von eGK lesen
    1
    6
    10,5
    7260
     
     
    2
    28
     
     
    3
    115
     
     
    4
    286
     
     
    NFD auf eGK schreiben
    1
    11
    10,5
    5780
     
     
    2
    51
     
     
    3
    213
     
     
    4
    533
     
     
    NFD von eGK löschen
    1
    1
    10,5
    4800
     
     
    2
    5
     
     
    3
    21
     
     
    4
    53
     
    I_DPE_Management
     
     
    DPE von eGK lesen
    1
    1
    1,5
    4300
     
     
    2
    3
     
     
    3
    14
     
     
    4
    36
     
     
    DPE auf eGK schreiben
    1
    1
    1,5
    4590
     
     
    2
    5
     
     
    3
    20
     
     
    4
    51
     
     
    DPE von eGK löschen
    1
    0,1
    1,5
    4260
     
     
    2
    0,5
     
     
    3
    2
     
     
    4
    5
     
    I_IDP_Auth_Active_Client
     
     
    issue_Identity_Assertion
     
     
    5
    2500
     
     
    renew_Identity_Assertion
     
     
    20
    2500
     
     
    cancel_Identity_Assertion
     
     
    20
    500
     
    I_IDP_Auth_Passive_Client
     
     
    signin
     
     
    2
    3500
     
     
    signout
     
     
    1
    500
     
    I_Local_IDP_Service
     
     
    sign_Token
     
     
    5
    2500
     
    I_AMTS_Service
     
     
    ReadMP
     
     
    30
    5268
     
     
    WriteMP (mit C2C)
     
     
    30
    6625
     
     
    WriteMP (ohne C2C)
     
     
    30
    4020
    Basisdienste
     
     
     
     
     
    I_Sign_Operations
     
     
    sign_Document
     
     
    10
    1010
     
     
    1
    217
    100
    1030
     
     
    2
    258
     
     
    3
    351
     
     
    4
    575
     
     
     
     
    1000
    1440
     
     
    sign_Document
    (XAdES, XML_25MB, enveloped)
     
    13
    25000
    10500
     
     
    sign_Document
    (CAdES, TIFF_25MB, detached)
     
    25000
    7300
     
     
    sign_Document
    (PAdES, PDFA_2b_25MB)
     
    25000
    7300
     
     
    verify_Document
     
     
    10
    1570
     
     
    1
    217
    100
    1600
     
     
    2
    258
     
     
    3
    351
     
     
    4
    575
     
     
     
     
    1000
    1930
     
     
    verify_Document
    (XAdES, XML_25MB, enveloped, IncludeRevocationInfo=false)
     
    13
    25000
    9000
     
     
    verify_Document
    (CAdES, TIFF_25MB, IncludeRevocationInfo=false)
     
    25000
    9000
     
     
    verify_Document
    (PAdES, PDFA_2b_25MB, IncludeRevocationInfo=false)
     
    25000
    10600
     
     
    external_Authenticate
     
     
     
    885
     
     
    get_Certificate
     
     
     
    220
     
    I_SAK_Operations
     
     
    sign_Document_QES
    (Stapelgröße 1)
     
     
    10
    3540
     
     
    1
    17
    100
    3790
     
     
    2
    65
     
     
    3
    177
     
     
    4
    442
     
     
     
     
    1000
    4070
     
     
    sign_Document_QES
    (XAdES, XML_25MB, enveloped)
     
     
    25000
    12810
     
     
    sign_Document_QES
    (CAdES, TIFF_25MB, detached)
     
     
    25000
    9610
     
     
    sign_Document_QES
    (PAdES, PDFA_2b_25MB)
     
     
    25000
    9610
     
     
    sign_Document_QES
    (Stapelgröße 2, 2 * 100 kB Dokumente)
    1
    3
    200
    8870
     
     
    2
    11
     
     
    3
    30
     
     
    4
    74
     
     
    verify_Document_QES
     
     
    10
    2580
     
     
    1
    10
    100
    2610
     
     
    2
    39
     
     
    3
    113
     
     
    4
    282
     
     
     
     
    1000
    2940
     
     
    verify_Document_QES
    (XAdES, XML_25MB, enveloped, IncludeRevocationInfo=false)
     
     
    25000
    10010
     
     
    verify_Document_QES
    (CAdES, TIFF_25MB, detached IncludeRevocationInfo=false)
     
     
    25000
    10010
     
     
    verify_Document_QES
    (PAdES, PDFA_2b_25MB, IncludeRevocationInfo=false)
     
     
    25000
    11610
     
    I_KV_Card_Unlocking
     
     
    authorize_Card (no Cache)
     
     
     
    2020
     
     
    authorize_Card (Cache)
     
     
     
    1830
     
    I_Crypt_Operations
     
     
    encrypt_Document
     
     
    10
    1860
     
     
    1
    217
    100
    1880
     
     
    2
    258
     
     
    3
    351
     
     
    4
    575
     
     
     
     
    1000
    2200
     
     
    encrypt_Document
    (XMLEnc, TIFF_25MB, ein Empfänger)
     
    13
    25000
    10600
     
     
    encrypt_Document
    (CMS, TIFF_25MB, ein Empfänger)
     
    25000
    7800
     
     
    decrypt_Document
     
     
    10
    490
     
     
    1
    217
    100
    510
     
     
    2
    258
     
     
    3
    351
     
     
    4
    575
     
     
     
     
    1000
    820
     
     
    decrypt_Document
    (XMLEnc, TIFF_25MB)
     
    13
    25000
    8900
     
     
    decrypt_Document
    (CMS, TIFF_25MB)
     
    25000
    8900
     
    I_Cert_Verification
     
     
    verifyCertificate
     
     
     
    1150
     
    I_Directory_Query
     
     
    search_Directory (TI-Plattform Dezentral)
    1
    200
     

    2220
     
     
    2
    300
     
     
    3
    500
     
     
    4
    1000


    Die Tabelle "Tab_gemSpec_Perf_Konnektor" führt alle Schnittstellen des Konnektors auf, an die Performance-Anforderungen gestellt werden. Zu allen aufgeführten Schnittstellen sind Vorgaben an die Schranke für „Mittelwert“ der Bearbeitungszeit angegeben. Wenn die Bearbeitungszeit abhängig von der „Größe der Anfragenachricht“ ist, ist die zugehörige Spalte gefüllt. Lastvorgaben beschränken sich auf typische Nachrichtengrößen. Bei den Lastvorgaben wird nach den Leistungserbringerumgebungen LE-U1, LE-U2, LE-U3, LE-U4 unterschieden.

    Zunächst wird die Einhaltung der Bearbeitungszeitvorgaben ohne Last gefordert (vgl. Abbildung 5: Quadrant 3):

    GS-A_4346 - Performance – Konnektor in LE-U1 – Bearbeitungszeit lastfrei

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U1 vorgesehen ist, MUSS die für diese Leistungserbringerumgebung in Tab_gemSpec_Perf_Konnektor vorgegebenen Schranken für Mittelwert der Bearbeitungszeit in 100 sequentiellen Einzelmessungen pro Schnittstellenoperation einhalten.
    [<=]

    GS-A_5096 - Performance – Konnektor in LE-U2 – Bearbeitungszeit lastfrei

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U2 vorgesehen ist, MUSS die für diese Leistungserbringerumgebung in Tab_gemSpec_Perf_Konnektor  vorgegebenen Schranken für Mittelwert der Bearbeitungszeit in 100 sequentiellen Einzelmessungen pro Schnittstellenoperation einhalten.
    [<=]

    GS-A_5097 - Performance – Konnektor in LE-U3 – Bearbeitungszeit lastfrei

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U3 vorgesehen ist, MUSS die für diese Leistungserbringerumgebung in Tab_gemSpec_Perf_Konnektor  vorgegebenen Schranken für Mittelwert der Bearbeitungszeit in 100 sequentiellen Einzelmessungen pro Schnittstellenoperation einhalten.
    [<=]

    GS-A_5098 - Performance – Konnektor in LE-U4 – Bearbeitungszeit lastfrei

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U4 vorgesehen ist, MUSS die für diese Leistungserbringerumgebung in Tab_gemSpec_Perf_Konnektor  vorgegebenen Schranken für Mittelwert der Bearbeitungszeit in 100 sequentiellen Einzelmessungen pro Schnittstellenoperation einhalten.
    [<=]

    Im nächsten Schritt werden die Lastangaben aus Tab_gemSpec_Perf_Konnektor berücksichtigt und Anforderungen zur Bearbeitungszeit unter Last gestellt (vgl. Abbildung 5: Quadrant 4).

    Dabei wird berücksichtigt, dass die Spitzenlasten der VSDM-Anwendungsfälle und die zu den Anwendungsfällen Signatur/Verschlüsselung gemäß Bedarfsvorgabe nicht zur gleichen Zeit auftreten.

    GS-A_4150 - Performance – Konnektor in LE-U1 – Parallele Verarbeitung VSDM

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U1 vorgesehen ist, MUSS parallel eintreffende VSDM-Anfragen an der Schnittstelle I_VSD_Service funktional korrekt bearbeiten und die Antwortzeitvorgaben für diese Leistungserbringerumgebung gemäß Tabelle "Tab_gemSpec_Perf_Konnektor" einhalten, soweit diese durch den Konnektor zu verantworten sind.

    Das Einhalten der Vorgabe wird durch die in Tabelle "Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B" definierten Tests für die Konstellationen mit einer SMC-B überprüft.
    [<=]

    GS-A_5099 - Performance – Konnektor in LE-U2 – Parallele Verarbeitung VSDM

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U2 vorgesehen ist, MUSS parallel eintreffende VSDM-Anfragen an der Schnittstelle I_VSD_Service funktional korrekt bearbeiten und die Antwortzeitvorgaben für diese Leistungserbringerumgebung gemäß Tabelle "Tab_gemSpec_Perf_Konnektor" einhalten, soweit diese durch den Konnektor zu verantworten sind.

    Das Einhalten der Vorgabe wird durch den in Tabelle "Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B" definierten Test für die Konstellation mit einer SMC-B überprüft.
    [<=]

    GS-A_5100 - Performance – Konnektor in LE-U3 – Parallele Verarbeitung VSDM

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U3 vorgesehen ist, MUSS parallel eintreffende VSDM-Anfragen an der Schnittstelle I_VSD_Service funktional korrekt bearbeiten und die Antwortzeitvorgaben für diese Leistungserbringerumgebung gemäß Tabelle "Tab_gemSpec_Perf_Konnektor" einhalten, soweit diese durch den Konnektor zu verantworten sind.

    Das Einhalten der Vorgabe wird durch die in Tabelle "Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B" definierten Tests für die Konstellationen mit einer SMC-B und zwei SMC-Bs überprüft.
    [<=]

    GS-A_5101 - Performance – Konnektor in LE-U4 – Parallele Verarbeitung VSDM

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U4 vorgesehen ist, MUSS parallel eintreffende VSDM-Anfragen an der Schnittstelle I_VSD_Service funktional korrekt bearbeiten und die Antwortzeitvorgaben für diese Leistungserbringerumgebung gemäß Tabelle "Tab_gemSpec_Perf_Konnektor" einhalten, soweit diese durch den Konnektor zu verantworten sind.

    Das Einhalten der Vorgabe wird durch die in Tabelle "Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B" definierten Tests für die Konstellationen mit einer SMC-B und zwei SMC-Bs überprüft.
    [<=]


    Tabelle 45: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B

    Konstellation
    Test
    eine SMC-B
    Der Konnektor muss eine Anzahl von n = 10 verschiedenen eGKs freischalten. Hierzu werden innerhalb von 1 sec n = 10 Anfragen „ReadVSD – mit Akt.-Prüfung, ohne Update“ gestartet. Die einzuhaltenden Vorgaben für die Bearbeitungszeiten sind:
    die schnellste Bearbeitungszeit < µ
    die langsamste Bearbeitungszeit < µ + (n - 1) * w
    die Summe der Bearbeitungszeiten < n * (µ + (n -1)/2 * w )

    w = 1 sec ist die Bearbeitungszeit für den wegen der Konstellation rein sequentiell erfolgenden Freischaltungsprozess zwischen eGKs und einer SMC-B.
    n ist die Zahl der parallel gestarteten Anfragen.
    µ ist die Schranke für den Bearbeitungszeitmittelwert gemäß Tabelle "Tab_gemSpec_Perf_Konnektor".
    zwei SMC-Bs
    Der Konnektor muss in einer Konstellation mit zwei SMC-Bs eine Anzahl von
    n = 10 verschiedenen eGKs freischalten. Hierzu werden innerhalb von 1 sec
    n = 10 Anfragen „ReadVSD – mit Akt.-Prüfung, ohne Update“ gestartet. Die einzuhaltenden Vorgaben für die Bearbeitungszeiten sind:
    die schnellste Bearbeitungszeit < µ
    die Summe der Bearbeitungszeiten
    < n * µ + (p*(p-1) + q*(q-1)) / 2 * w
    mit p = (n – n mod 2)/2, q = (n + n mod 2)/2

    w = 1 sec ist die Bearbeitungszeit für den wegen der Konstellation rein sequentiell erfolgenden Freischaltungsprozess zwischen eGKs und einer SMC-B.
    n ist die Zahl der parallel gestarteten Anfragen.
    µ ist die Schranke für den Bearbeitungszeitmittelwert gemäß Tabelle "Tab_gemSpec_Perf_Konnektor".

    Hinweis: Der in den Anforderungen GS-A_4150, GS-A_5099, GS-A_5100, GS-A_5101 dargestellte Test soll den konkurrierenden Zugriff auf die SMC-B als knappe Ressource testen. Da die Situation im Fall der vielfach schnelleren HSMs nicht besteht, richtet sich die Testvorschrift an Konnektoren mit SMC-Bs und nicht an Konnektoren mit HSM-Bs.

    Für die parallele Verarbeitung der Operationsaufrufe an den Basisdienstschnittstellen wird folgendes gefordert:

    GS-A_4151 - Performance – Konnektor in LE-U1 – Parallele Verarbeitung

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U1 vorgesehen ist, MUSS für eine reibungsfreie parallele Verarbeitung sämtlicher Operationsaufrufe an den Schnittstellen des Anwendungskonnektors sorgen, was wie folgt getestet wird: Für die in Tabelle "Tab_gemSpec_Perf_Konnektor"  angegebenen Operationen mit Lastangabe wird für alle Operationen gemeinsam eine Testanfragenrate erzeugt, die eine den Lastangaben für diese Leistungserbringerumgebung entsprechende Zusammenstellung von Aufrufen repräsentiert. Die Aufrufe müssen innerhalb der Antwortzeitvorgaben korrekt bearbeitet werden.
    [<=]

    GS-A_5102 - Performance – Konnektor in LE-U2 – Parallele Verarbeitung

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U2 vorgesehen ist, MUSS für eine reibungsfreie parallele Verarbeitung sämtlicher Operationsaufrufe an den Schnittstellen des Anwendungskonnektors sorgen, was wie folgt getestet wird: Für die in Tabelle "Tab_gemSpec_Perf_Konnektor"  angegebenen Operationen mit Lastangabe wird für alle Operationen gemeinsam eine Testanfragenrate erzeugt, die eine den Lastangaben für diese Leistungserbringerumgebung entsprechende Zusammenstellung von Aufrufen repräsentiert. Die Aufrufe müssen innerhalb der Antwortzeitvorgaben korrekt bearbeitet werden.
    [<=]

    GS-A_5103 - Performance – Konnektor in LE-U3 – Parallele Verarbeitung

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U3 vorgesehen ist, MUSS für eine reibungsfreie parallele Verarbeitung sämtlicher Operationsaufrufe an den Schnittstellen des Anwendungskonnektors sorgen, was wie folgt getestet wird: Für die in Tabelle "Tab_gemSpec_Perf_Konnektor"  angegebenen Operationen mit Lastangabe wird für alle Operationen gemeinsam eine Testanfragenrate erzeugt, die eine den Lastangaben für diese Leistungs-erbringerumgebung entsprechende Zusammenstellung von Aufrufen repräsentiert. Die Aufrufe müssen innerhalb der Antwortzeitvorgaben korrekt bearbeitet werden.
    [<=]

    GS-A_5104 - Performance – Konnektor in LE-U4 – Parallele Verarbeitung

    Jeder Konnektor, der für den Einsatz in der Leistungserbringerumgebung LE-U4 vorgesehen ist, MUSS für eine reibungsfreie parallele Verarbeitung sämtlicher Operationsaufrufe an den Schnittstellen des Anwendungskonnektors sorgen, was wie folgt getestet wird: Für die in Tabelle "Tab_gemSpec_Perf_Konnektor"  angegebenen Operationen mit Lastangabe wird für alle Operationen gemeinsam eine Testanfragenrate erzeugt, die eine den Lastangaben für diese Leistungserbringerumgebung entsprechende Zusammenstellung von Aufrufen repräsentiert. Die Aufrufe müssen innerhalb der Antwortzeitvorgaben korrekt bearbeitet werden.
    [<=]

    Für die parallele Verarbeitung der Operationsaufrufe zur Tokenbasierten Authentisierung wird folgendes gefordert:

    GS-A_5486 - Performance – Parallele Verarbeitung zur Tokenbasierten Authentisierung

    Der Konnektor MUSS für eine reibungsfreie parallele Verarbeitung der Aufrufe der Operationen an den Schnittstellen I_IDP_Auth_Active_Client, I_IDP_Auth_Passive_Client und I_Local_IDP_Service sorgen, was wie folgt getestet wird: Es werden jeweils zwei Aufrufe zu I_IDP_Auth_Active_Client:issue_Identity_Assertion, ein Aufruf zu I_Local_IDP_Service:sign_Token gestartet. Die Messung der Bearbeitungszeiten ist 100 Mal auszuführen. Es sind die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_Konnektor einzuhalten.

    [<=]

    GS-A_5487 - Performance – Konnektor – Parallele Verarbeitung AMTS

    Der Konnektor MUSS parallel eintreffende AMTS-Anfragen funktional korrekt bearbeiten und die Antwortzeitvorgaben gemäß Tabelle "Tab_gemSpec_Perf_Konnektor" einhalten, soweit diese durch den Konnektor zu verantworten sind.
    Das Einhalten der Vorgabe wird durch die in Tabelle "Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B_AMTS" definierten Tests für die Konstellationen mit einer SMC-B überprüft.
    [<=]

    Tabelle 46: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B_AMTS

    Konstellation
    Test
    eine SMC-B
    Der Konnektor muss eine Anzahl von n = 10 verschiedenen eGKs freischalten. Hierzu werden innerhalb von 1 sec n = 10 Anfragen „ReadMP“ gestartet. Die einzuhaltenden Vorgaben für die Bearbeitungszeiten sind:
    die schnellste Bearbeitungszeit < µ
    die langsamste Bearbeitungszeit < µ + (n - 1) * w
    die Summe der Bearbeitungszeiten < n * (µ + (n -1)/2 * w )

    w = 1 sec ist die Bearbeitungszeit für den wegen der Konstellation rein sequentiell erfolgenden Freischaltungsprozess zwischen eGKs und einer SMC-B.
    n ist die Zahl der parallel gestarteten Anfragen.
    µ ist die Schranke für den Bearbeitungszeitmittelwert gemäß Tabelle "Tab_gemSpec_Perf_Konnektor".


    Hinweis: Die Bearbeitungszeitvorgaben wurden unter der Annahme bestimmt, dass die Implementierung hinsichtlich Caching und Parallelisierbarkeit innerhalb eines Anwendungsfalls optimiert sind.


    Stapelsignatur und gSMC-Ks

    Bei der Operation sign_Document_QES in Tabelle "Tab_gemSpec_Perf_Konn" wurde gemäß Lastmodell aus Kapitel 3.1.7 davon ausgegangen, dass 25% der Signaturen per Stapelsignatur (Annahme Lastmodell: Stapelgröße 2) erfolgen. Tabelle "Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell" stellt für diese Situation dar, wie groß die Wahrscheinlichkeit ist, dass n Stapelsignaturen oder mehr parallel erfolgen müssen.

    Tabelle 47: Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell

    Lastvorgaben
    Mittelwert Bearbeitungs-
    zeit
    [msec]
    Sp.Last * Mittelwert Bearbeitungs-
    zeit [msec]
    Wahrscheinlichkeit in % für n oder mehr parallele Bearbeitungen
    L
    E
    -U
    Spitzen-
    lasten
    [1/h]
    n=1
    n=2
    n=3
    n=4
    n=5
    n=6
    1
    3
    8870
    0,01
    1
    0
    0
    0
    0
    0
    2
    11
    0,03
    3
    0
    0
    0
    0
    0
    3
    30
    0,07
    7
    0
    0
    0
    0
    0
    4
    74
    0,18
    17
    1
    0
    0
    0
    0


    In der Tabelle "Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell" sind alle Wahrscheinlichkeiten über 1% rot markiert, weil hier davon ausgegangen wird, dass die Vorgaben nur erreicht werden können, wenn eine vollständige parallele Verarbeitung der Anfragen erfolgt. Geht man davon aus, dass pro gSMC-K drei logische Kanäle für die parallele Verarbeitung von Stapelsignaturen zur Verfügung stehen, dann folgt daraus, dass für das angenommene Lastszenario der Einsatz einer gSMC-K ausreichend ist.

    Der Konnektor muss jedoch auch auf ein geändertes Nutzungsverhalten vorbereitet sein, wie es durch verstärkte Nutzung oder systematische Häufung von Anfragen gegen Schichtende oder durch eine verstärkte Nutzung der Stapelsignatur hervorgerufen werden kann. Angenommen in einer Leistungserbringerumgebung wird dadurch (zusätzlich zum angenommenen Spitzenlastfaktor) die Last um den Faktor 30 erhöht, dann stellt sich die Situation aus Tabelle "Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell" wie folgt dar:

    Tabelle 48: Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch – Parallelverarbeitung perspektivisch

    Last
    Mittelwert Bearbeitungs-
    zeit
    [msec]
    Sp.Last * Mittelwert Bearbeitungs-
    zeit [msec]
    Wahrscheinlichkeit in% für n oder mehr parallele Bearbeitungen
    L
    E
    -U
    Sp.-lasten
    [1/h]
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    1
    90
    8870
    0,2
    19
    2
    0
    0
    0
    0
    0
    0
    0
    0
    0
    0
    2
    330
    0,8
    55
    19
    5
    1
    0
    0
    0
    0
    0
    0
    0
    0
    3
    900
    2,2
    89
    64
    37
    18
    7
    2,4
    1
    0
    0
    0
    0
    0
    4
    2220
    5,4
    100
    97
    91
    79
    63
    46
    31
    18
    10
    5
    2
    1

    Um auch die perspektivischen Lastbedingungen erfüllen zu können, wird daher gefordert:

    GS-A_5059 - Performance – Stapelsignatur Konnektor für LE-U1 im Auslieferungszustand

    Der Konnektor MUSS im Auslieferungszustand für den Einsatz in der Leistungserbringerumgebung LE-U1 die Bearbeitungszeitvorgaben unter Last für LE-U1 gemäß Tabelle "Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch" erfüllen.
    [<=]

    GS-A_5105 - Performance – Stapelsignatur Konnektor für LE-U2 im Auslieferungszustand

    Der Konnektor MUSS im Auslieferungszustand für den Einsatz in der Leistungserbringerumgebung LE-U2 die Bearbeitungszeitvorgaben unter Last für LE-U2 gemäß Tabelle "Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch" erfüllen.
    [<=]

    Für die Erfüllung dieser Lastbedingungen ist es möglicherweise erforderlich, dass der Konnektor initial mit mindestens zwei gSMC-Ks ausgestattet ist.

    GS-A_5036 - Performance – Stapelsignatur Konnektor für LE-U3

    Der Konnektor MUSS für den Einsatz in der Leistungserbringerumgebung LE-U3 die Bearbeitungszeitvorgaben unter Last gemäß Tabelle "Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch" erfüllen. Diese Leistung MUSS er entweder bereits im Auslieferungszustand erbringen oder durch Nachrüstung im Feld mit weiteren gSMC-Ks erbringen können.
    [<=]

    Für die Erfüllung dieser Lastbedingungen ist es möglicherweise erforderlich, dass der Konnektor initial mit mindestens drei gSMC-Ks ausgestattet ist.

    GS-A_5106 - Performance – Stapelsignatur Konnektor für LE-U4

    Der Konnektor MUSS für den Einsatz in der Leistungserbringerumgebung LE-U4 die Bearbeitungszeitvorgaben unter Last gemäß Tabelle "Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch" erfüllen. Diese Leistung MUSS er entweder bereits im Auslieferungszustand erbringen oder durch Nachrüstung im Feld mit weiteren gSMC-Ks erbringen können.
    [<=]

    Für die Erfüllung dieser Lastbedingungen ist es möglicherweise erforderlich, dass der Konnektor initial mit mindestens vier gSMC-Ks ausgestattet ist.

    Damit zugelassene Konnektoren auch im Zusammenspiel mit G2-Karten unterschiedlicher CV-Roots die Anwendungsfälle aus Tab_gemSpec_Perf_Konnektor in akzeptabler Zeit durchführen, wird folgende Anforderung im Kontext einer definierten Rahmenbedingung für die Test- und Zulassungsverfahren gestellt:

    GS-A_5247 - Performance – Konnektor – G2-Karten mit unterschiedlicher CV-Root

    Der Konnektor MUSS sämtliche Performancevorgaben mit den Vorgabezeiten aus Tab_gemSpec_Perf_Konnektor auch für die Ausführung mit G2-Karten mit unterschiedlicher CV-Root erfüllen.

    Rahmenbedingung für diese Vorgabe ist, dass in maximal einem von hundert Anwendungsfällen die CV-Root der zu authentifizierenden Karte nicht auf der authentifizierenden Karte vorhanden ist.
    [<=]

    Rahmenbedingungen für die Messungen:

    Abbildung 6: Messpunkte zur Konnektor Performance-Messung


    Die dem Konnektor zugerechneten Bearbeitungszeiten sind die Antwortzeit auf einen Schnittstellenaufruf im Clientsystem (tE – tA) abzüglich der Summe aller Antwortzeiten von FA-spezifischen Diensten (Summe ti,e – ti,a). Definition der Messzeitpunkte:

    Alle übrigen Aufrufe liegen im Verantwortungsbereich des Konnektors. Tatsächlich verantworten kann er nur die Koordination der Aufrufe nicht das tatsächliche Antwortzeitverhalten, das von den koordinierten dezentralen Produkttypen (Kartenterminals und Smartcards) abhängt. Für die Antwortzeitvorgaben wurden daher dezentrale Produkttypen mit einem normierten Verhalten gewählt, das wie folgt definiert ist:

    Die konkreten Dokumente zu diesen Bezeichnern legt die Dokumentenlandkarte fest.


    Netzwerkebene

    Der Konnektor ermöglicht neben der Anbindung fachanwendungsspezifischer Dienste, der Anbindung an Bestandsnetze auch die Nutzung eines Internetzugangs.

    GS-A_4152 - Performance - Konnektor – Bandbreitenunterstützung

    Der Produkttyp Konnektor MUSS die am Markt üblichen Bandbreiten für Internetzugänge unterstützen.

    [<=]

    GS-A_5509 - Performance – Konnektor (Ausbaustufe VSDM) – IPSec-Tunnel TI und SIS

    Der Produkttyp Konnektor MUSS einen IPSec-Durchsatz von mindestens
    25 Mbit/s bidirektional und kontinuierlich erreichen. Der Wert gilt in Summe für IPSec-Tunnel TI und SIS.

    [<=]

    Die Anforderung GS-A_5509 gilt ausschließlich für den Konnektor (Ausbaustufe VSDM).

    GS-A_5543 - Performance – Konnektor – IPSec-Tunnel TI und SIS

    Der Produkttyp Konnektor MUSS einen IPSec-Durchsatz von mindestens
    30 Mbit/s bidirektional und kontinuierlich erreichen. Der Wert gilt in Summe für IPSec-Tunnel TI und SIS.

    [<=]

    Die folgende Abbildung erläutert die Durchsatzmessung.


    Abbildung 7: Messaufbau zum IPSec-Durchsatzmessung


    Der geforderte IPSec-Durchsatz wird unter folgenden Bedingungen ermittelt:

    Verfügbarkeit

    Aus dem Bedarf, einen nicht funktionsfähigen Konnektor im Krankenhaus zeitnah gegen einen bereitstehenden Ersatzkonnektor austauschen zu können, leitet sich folgende Anforderung ab:

    GS-A_4153 - Performance – Konnektor in LE-U1 – Verfügbarkeit

    Der Konnektor MUSS eine technische Wiederherstellungszeit von 15 Minuten unter der Voraussetzung der Verfügbarkeit von vorliegenden gesicherten und kompatiblen Konfigurationsdaten einhalten.

    Die Wiederherstellungszeit endet mit einem erfolgreich durchgeführten Boot-Up des neuen Konnektors. Es sind für LE-U1 20 Kartenterminals zu berücksichtigen.
    [<=]

    GS-A_5107 - Performance – Konnektor in LE-U2 – Verfügbarkeit

    Der Konnektor MUSS eine technische Wiederherstellungszeit von 15 Minuten unter der Voraussetzung der Verfügbarkeit von vorliegenden gesicherten und kompatiblen Konfigurationsdaten einhalten.

    Die Wiederherstellungszeit endet mit einem erfolgreich durchgeführten Boot-Up des neuen Konnektors. Es sind für LE-U2 45 Kartenterminals zu berücksichtigen.
    [<=]

    GS-A_5108 - Performance – Konnektor in LE-U3 – Verfügbarkeit

    Der Konnektor MUSS eine technische Wiederherstellungszeit von 15 Minuten unter der Voraussetzung der Verfügbarkeit von vorliegenden gesicherten und kompatiblen Konfigurationsdaten einhalten.

    Die Wiederherstellungszeit endet mit einem erfolgreich durchgeführten Boot-Up des neuen Konnektors. Es sind für LE-U3 125 Kartenterminals zu berücksichtigen.
    [<=]

    GS-A_5109 - Performance – Konnektor in LE-U4 – Verfügbarkeit

    Der Konnektor MUSS eine technische Wiederherstellungszeit von 15 Minuten unter der Voraussetzung der Verfügbarkeit von vorliegenden gesicherten und kompatiblen Konfigurationsdaten einhalten.

    Die Wiederherstellungszeit endet mit einem erfolgreich durchgeführten Boot-Up des neuen Konnektors. Es sind für LE-U4 300 Kartenterminals zu berücksichtigen.
    [<=]

    GS-A_5332 - Performance – Konnektor – Robustheit gegenüber Lastspitzen

    Der Konnektor MUSS bei Lastspitzen oberhalb der für ihn definierten Spitzenlasten verfügbar bleiben.

    [<=]

    Aktualisierung des Vertrauensraumes

    Die Aktualisierung des Vertrauensraumes geschieht in den Konnektoren automatisch. Folgende Anforderung sorgt dafür, dass es nicht zu einer unnötig zeitlich gebündelten Aktualisierung des Vertrauensraumes aller Konnektoren kommt, was zu einer unverhältnismäßig großen Spitzenlast für den OCSP-Dienst des TSL-Signerzertifikats führen würde.

    GS-A_4356 - Performance - Konnektor –Aktualisierung Vertrauensraum

    Der Produkttyp Konnektor MUSS dafür sorgen, dass die von ihm über sämtliche Konnektorinstanzen in der TI im Rahmen der TSL-Aktualisierung ausgelösten Downloads der TSL und die OCSP-Responder-Aufrufe zum Prüfen des TSL-Signerzertifikats möglichst gleichmäßig über den Tag verteilt sind. Die zu erwartende Spitzenlast darf nicht größer sein als bei einer Gleichverteilung über eine Stunde.

    [<=]

    Aktualisierung der BNetzA-VL

    Wie beim Download der TSL muss beim Download der BNetzA-VL durch den Konnektor für die Vermeidung zu hoher Spitzenlasten gesorgt werden.

    GS-A_5490 - Performance – Konnektor – Aktualisierung BNetzA-VL

    Der Produkttyp Konnektor MUSS dafür sorgen, dass die von ihm über sämtliche Konnektorinstanzen in der TI im Rahmen der BNetzA-VL-Aktualisierung ausgelösten Downloads der BNetzA-VL möglichst gleichmäßig über den Tag verteilt sind. Pro Konnektorinstanz darf maximal ein vollständiger Download einer BNetzA-VL pro Tag erfolgen. Die zu erwartende Spitzenlast darf nicht größer sein als bei einer Gleichverteilung über vier Stunden.
    [<=]

    Software Download

    Ebenso wie bei der automatischen Aktualisierung des Vertrauensraumes gilt es beim automatisierten Download von Softwarepaketen unnötige Lastspitzen zu vermeiden:

    GS-A_5013 - Performance – Konnektor – Software Download

    Der Produkttyp Konnektor MUSS dafür sorgen, dass die von ihm über sämtliche Konnektorinstanzen in der TI automatisiert ausgelösten Downloads von Softwarepaketen möglichst gleichmäßig über den Tag verteilt starten.

    [<=]

    Performance Logging

    Zur Unterstützung der Performance-Analyse wird die Erfassung der Bearbeitungszeiten pro Aufruf in einem konfigurierbaren Erfassungszeitraum ermöglicht.

    GS-A_5130 - Performance – Konnektor – Performance Logging

    Der Produkttyp Konnektor MUSS ein Performance Logging für alle fachlichen und administrativen Anwendungsfälle erlauben. Über die Managementschnittstelle des Konnektors muss das Performance Logging per Konfiguration ein- und ausschaltbar sein (Default-Wert: ausgeschaltet).

    Logging pro Anwendungsfallausführung


    Für jede Ausführung eines Anwendungsfalls (etwa durch Aufruf einer Operation an der Außenschnittstelle des Konnektors) sind folgende Werte zu erfassen:

    [<=]

    Skalierbarkeit

    Um die Skalierbarkeit des Konnektors auf weitere Anwendungen zu unterstützen, werden folgende Anforderungen gestellt:

    GS-A_5325 - Performance – Konnektor – Kapazitätsplanung

    Der Konnektorhersteller MUSS die internen Ressourcen des Konnektors (Prozessor, Hauptspeicher, Persistenter Speicher, etc.) so wählen, dass die Performance-Anforderungen für neue Anwendungen durch alleiniges Update der Firmware erreicht werden können.

    Dabei muss der Konnektor den Ressourcenbedarf von 8 durchschnittlichen Anwendungen für die vorgesehene Leistungserbringerumgebung abdecken. Der Ressourcenbedarf einer durchschnittlichen Anwendung wird als der Gesamtressourcenbedarf der gemäß Tabelle "Tab_gemSpec_Perf_Konnektor"
    bereitzustellenden Performanceleistung (VSDM, KOM-LE, QES) geteilt durch 3 definiert.

    Den konkret ermittelten Ressourcenbedarf muss der Hersteller in einem Skalierungskonzept darstellen.

    Das Skalierungskonzept muss

    [<=]

    GS-A_5326 - Performance – Konnektor – Hauptspeicher

    Der Konnektor SOLL einen Hauptspeicher von mindestens 2 GByte haben.

    [<=]

    GS-A_5327 - Performance – Konnektor – Skalierbarkeit

    Der Konnektor MUSS die von 8 durchschnittlichen Anwendungen erzeugte Last im vorgegebenen Bearbeitungszeitrahmen für die vorgesehene Leistungserbringerumgebung bedienen können. Dabei wird die erzeugte Last einer durchschnittlichen Anwendung als die durch Tabelle "Tab_gemSpec_Perf_Konnektor" definierte Last (VSDM, KOM-LE, QES) geteilt durch 3 definiert.
    [<=]

    Der Test von [GS-A_5327] erfolgt für den VSDM-Konnektor anhand eines QES-Produktmusters. Das QES-Produktmuster muss dafür funktional nur soweit implementiert sein, dass eine Überprüfung der Bearbeitung paralleler Requests unter der Ziellast möglich ist. Welche Tests durchgeführt werden und welche Eigenschaften dafür beim QES-Produktmuster erforderlich sind, beschreibt „Anhang D – Performancerelevante Produktmustereigenschaften des QES-Konnektors“.

    Der Test von [GS-A_5327] erfolgt für den QES-Konnektor vom Verfahren her analog den Tests für den VSDM-Konnektor. Getestet wird an Hand eines breiteren Spektrums von Signatur- und Verschlüsselungsverfahren, beschrieben in „Anhang E – Testverfahren zur Prüfung der Skalierungsfähigkeit des QES-Konnektors“.

    TLS-Verbindungsaufbau

    GS-A_5328 - Performance – Konnektor – TLS-Handshake

    Der Konnektor MUSS bei jedem TLS-Handshake die von ihm in Summe verursachten Zeiten im Fall beidseitiger Authentisierung unter 2 sec und im Fall einseitiger Authentisierung unter 1,5 sec halten. Die Anforderung gilt unabhängig davon, ob der Konnektor als TLS-Server oder TLS-Client agiert.

    [<=]

    GS-A_5333 - Performance – Konnektor – TLS Session Resumption 1

    Der Konnektor MUSS TLS Session Resumption mittels Session-ID gemäß RFC5246 nutzen, um für den wiederholten Aufbau von TLS-Verbindungen zu fachanwendungsspezifischen Diensten oder zentralen Diensten der TI-Plattform die bereits ausgehandelten TLS-Session wiederzuverwenden und damit den TLS-Handshake abzukürzen, sofern TLS-Session Resumption vom jeweiligen Kommunikationspartner angeboten wird.

    [<=]

    GS-A_5334 - Performance – Konnektor – TLS Session Resumption 2

    Der Konnektor MUSS TLS Session Resumption mittels Session-ID gemäß RFC5246 für TLS-gesicherte Verbindungen zum Clientsystem unterstützen, um für den wiederholten Aufbau von TLS-Verbindungen die bereits ausgehandelten TLS-Session wiederzuverwenden und damit den TLS-Handshake abzukürzen.

    [<=]

    5.1.2.1 Fachmodul ePA

    Die Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben" definiert für die Schnittstellenoperationen des Fachmodules ePA die Spitzenlastvorgaben mit den jeweilig einzuhaltenden Bearbeitungszeiten.

    Tabelle 49: Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben

    Schnittstellenoperationen
    Last
    Bearbeitungszeit
    L
    E
    -U
    Spitzen-
    lasten
    [1/h]
    Größe der Anfrage-nachricht
    [kByte]


    Mittelwert
    [msec]
    PHRService
     
    find
    1
    7
    3
    115
     
    2
    5
     
    3
    14
     
    4
    35
     
    getDocuments
    1
    1
    10
    275
     
    2
    1
     
    3
    3
     
    4
    6
     
     
     
    100
    290
     
    1
    5
    1000
    600
     
    2
    3
     
    3
    6
     
    4
    15
     
     
     
    25000
    8680
     
    putDocuments
    1
    1
    10
    470
     
    2
    1
     
    3
    3
     
    4
    8
     
     
     
    100
    485
     
    1
    1
    1000
    805
     
    2
    7
     
    3
    18
     
    4
    44
     
     
     
    25000
    9205
     
    removeDocuments
    1
    1
    2
    115
     
    2
    1
     
    3
    2
     
    4
    6
     
    updateDocumentSet
     
     
    11
    115
    PHRManagementService
     
    requestFacilityAuthorization
     
     
     
    18715

    A_17490 - Performance - Fachmodul ePA - Bearbeitungszeit

    Das Fachmodul ePA MUSS die Bearbeitungszeitvorgaben aus Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben" erfüllen.

    Das Fachmodul ePA MUSS für die Zulassung den Nachweis für eine Sequenz von 100 aneinander folgende Anfragen je Schnittstellenoperation erbringen. Hierbei darf die mittlere Bearbeitungszeit nicht größer als die in Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben" definierte mittlere Bearbeitungszeit sein. Ebenfalls müssen die Aufrufe innerhalb der definierten Bearbeitungszeit korrekt bearbeitet werden. Es wird davon ausgegangen, das ein Login bereits durchgeführt worden ist.
    [<=]

    A_16174 - Performance - Fachmodul ePA - Bearbeitungszeit für Login

    Das Fachmodul ePA MUSS für die Schnittstellenoperationen aus Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben" das implizite Login von 7,7 Sekunden zusätzlich in die Bearbeitungszeit der Schnittstellenoperationen mit berücksichtigen. Sollte das Login schon durchgeführt worden sein, gilt für die Schnittstellenoperationen die mittlere Bearbeitungszeit aus der Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben".
    [<=]

    Beispielsweise ist für die Ausführung der Operation PHRService::find mit Berücksichtigung des impliziten Logins eine Bearbeitungszeitvorgabe unter 7815 ms einzuhalten.

    A_17491 - Performance - Fachmodul ePA - Parallele Verarbeitung

    Das Fachmodul ePA MUSS parallel eintreffende Anfragen an der Schnittstelle PHRService funktional korrekt bearbeiten und die Antwortzeitvorgaben aus Tabelle "Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben" einhalten. Mehrere Anfragen gelten dann als parallel, wenn sie in einem Zeitraum von maximal 5 msec an der Schnittstelle PHRService eingehen.

    Das Fachmodul ePA MUSS für die Zulassung die Testfälle aus der Tabelle "Tab_gemSpec_Perf_ePA_Parallele_Verarbeitung" für die jeweilige Leistungserbringer-Umgebung bestehen.

    Tabelle 50 : Tab_gemSpec_Perf_ePA_Parallele_Verarbeitung

    LE-Umgebung
    Test
    LE-U1 - LE-U2
    Das Fachmodul ePA muss für diese Leistungserbringer-Umgebungen mindestens 2 parallel eintreffende Anfragen funktional korrekt bearbeiten.
    Für den Nachweis werden folgende Testfälle überprüft:

    - 2 parallel eintreffende getDocuments Anfragen (10kB und 25000kB)
    - 2 parallel eintreffende putDocuments Anfragen (10kB und 25000kB)
    - 1 getDocuments und 1 putDocuments parallel eintreffende Anfragen
    - 1 find und 1 getDocuments parallel eintreffende Anfragen
    LE-U3 - LE-U4
    Das Fachmodul ePA muss für diese Leistungserbringer-Umgebungen mindestens 4 parallel eintreffende Anfragen funktional korrekt bearbeiten.
    Für den Nachweis werden folgende Testfälle überprüft:

    - 4 parallel eintreffende getDocuments Anfragen
    - 4 parallel eintreffende putDocuments Anfragen
    -  2 getDocuments und 2 putDocuments parallel eintreffende Anfragen
    - 2 find und 2 getDocuments parallel eintreffende Anfragen
    [<=]

    A_17803 - Performance - Fachmodul ePA - Bedingungen für die Messung

    Das Fachmodul ePA MUSS die folgenden Bedingungen einhalten:

    Vorbedingungen für die Messungen
    Es wird davon ausgegangen, dass nach einem Login-Prozess alle Verbindungsaufbauten erfolgten und zugehörige OCSP-Statusauskünfte im OCSP-Cache vorliegen.

    Rahmenbedingungen für die Messung
    Die dem Fachmodul ePA zugerechneten Bearbeitungszeiten für die Schnittstelle PHRService ist die Zeitspanne vom Senden einer Request bis zum Eingang der zugehörigen Response der Schnittstellenoperation an der  Schnittstelle zum Clientsystem abzüglich der Summe aller Verarbeitungszeiten von ePA-spezifischen Diensten.

    Die dem Fachmodul ePA zugerechneten Bearbeitungszeiten für die Schnittstelle PHRManagementService sind die Antwortzeiten für einen Request-Response Zyklus. Hierbei muss die Nutzerinteraktion (PIN-Eingabe) rausgerechnet werden.
    [<=]

    5.1.3 Produkttyp eHealth-Kartenterminal

    GS-A_4154 - Performance – Kartenterminal – Bearbeitungszeit

    Der Produkttyp Kartenterminal SOLL die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_Kartenterminal_Bearbeitungszeitvorgabe erfüllen. Nur bei eHealth-Kartenterminals, die auf bereits zugelassenen eHealth-BCS-Geräten basieren, kann eine Nichterfüllung der Anforderung akzeptiert werden.

    [<=]

    Tabelle 51: Tab_gemSpec_Perf_Kartenterminal_Bearbeitungszeitvorgabe

    Schnittstellenoperation
    Antwortzeitvorgaben
    Datenmenge
    [Byte]
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    Infrastrukturdienste
     
    I_KT_Communication
     
     
    transfer_APDU(readBinary)
    2000
    150
    240
     
     
    transfer_APDU(updateBinary)
    2000
    150
    240

    Rahmenbedingungen für die Messungen:

    Abbildung 8: Messpunkte zur Kartenterminal Performance-Messung

    Zur Messung werden Kommandos sequentiell gesendet, eine Parallelisierung von Kommandos durch das eHealth-Kartenterminal wird nicht betrachtet.

    Der Messaufbau skizziert in Abbildung 8 besteht aus drei Komponenten: dem Konnektor (oder Konnektorsimulator), dem zu messenden Kartenterminal sowie einer normierten Karte.

    Das zu messende Kommando wird zum Kartenterminal, in dem die normierte Karte steckt, gesendet. Der Zeitpunkt, bei dem das erste Byte des ersten Pakets des Kommando-Requests im Netzwerk übertragen wird, definiert den Beginn der Messung tA. Das Ende der Messung ist durch den Zeitpunkt tE bestimmt, wenn das letzte Byte des letzten Pakets der Kommando-Response empfangen wird.

    Die verwendete normierte Karte verhält sich elektrisch, mechanisch und protokolltechnisch konform zur eGK-Spezifikation und wird über einen Messadapter in das zu messende Kartenterminal gesteckt. An dem Messadapter wird dabei die reine Kartenlaufzeit für das zu messende Kommando messtechnisch ermittelt (tK = tEK – tAK, mit tAK als dem Zeitpunkt der Übertragung des ersten Bytes des Kommandos und tEK dem Zeitpunkt der Versendung des letzten Bytes der zugehörigen Response).

    Damit ergibt sich durch Rechnung die ermittelte Bearbeitungszeit des eHealth-Kartenterminals (tKT), in Abhängigkeit des Kommandos c wie folgt:

    tKT(c) = (tE –tA)  – tK


    TLS-Verbindungsaufbau

    GS-A_5329 - eHealth-KT Performance – TLS-Handshake I

    Der Produkttyp eHealth-Kartenterminal SOLL sicherstellen, dass die durch ihn verursachte Zeit während jedes TLS-Handshakes insgesamt maximal 5 sec beträgt.

    Nur bei eHealth-Kartenterminals, die auf bereits zugelassenen eHealth-BCS-Geräten basieren, kann eine Nichterfüllung der Anforderung akzeptiert werden.
    [<=]

    GS-A_5330 - eHealth-KT Performance – TLS-Handshake II

    Der Produkttyp eHealth-Kartenterminal DARF bei der durch ihn verursachten Zeit während des TLS-Handshakes insgesamt 45 sec NICHT überschreiten.

    [<=]

    Die Anforderung [GS-A_5330] ist somit insbesondere auch von Geräten zu erfüllen, die auf bereits zugelassenen eHealth-BCS-Geräten basieren.


    Rahmenbedingungen für die Messungen der Dauer des TLS-Handshakes:

    Zur Messung der Dauer des TLS-Handshakes werden die durch das eHealth-Kartenterminal verursachten Zeiten vom Empfang des Client Hello durch das eHealth-Kartenterminal bis zu ChangeCipherSpec Finished gemessen und addiert. Latenzzeiten des Transportnetzes gehen in die Berechnung der Dauer nicht ein.

    5.1.4 Produkttyp Mobiles Kartenterminal

    An das Mobile Kartenterminal werden keine Performance-Anforderungen gestellt.

    5.1.5 Produkttyp KTR-AdV

    An den Produkttypen KTR-AdV werden Anforderungen bezüglich seiner Verfügbarkeit gestellt.

    GS-A_5506 - Performance – AdV-Server – Verfügbarkeit

    Der Produkttyp KTR-AdV MUSS für die Komponente AdV-Server zur Hauptzeit und zur Nebenzeit eine Verfügbarkeit von 98% haben.

    Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
    [<=]

    Weitere Anforderungen: [GS-A_4146], [GS-A_4149]

    5.2 Produkttypen der zentralen Zone der TI-Plattform

    Um eine hohe Verfügbarkeit der TI-Plattform zu gewährleisten wird für alle Produkttypen der zentralen Zone der TI-Plattform, deren Verfügbarkeit zur Gesamtverfügbarkeit einzelner Anwendungsfälle wesentlich beiträgt, eine hohe Verfügbarkeit gefordert. Ebenso wird dies für die Störungsampel gefordert, die ein zeitnahes Monitoring von Ausfällen erlauben soll.

    GS-A_4155 - Performance – zentrale Dienste – Verfügbarkeit

    Die Produkttypen Namensdienst, Sicherheitsgateway Bestandsnetze, VPN-Zugangsdienst, OCSP-Proxy, TSP-X.509QES (Komponente OCSP-Responder), TSP-X.509nonQES (Komponente OCSP-Responder /CRL-Dienst und Komponente Provisioning/Revocation), gematik-Root-CA (Komponente OCSP-Responder), Verzeichnisdienst, Service Monitoring, Signaturdienst und die Störungsampel MÜSSEN zur Hauptzeit eine Verfügbarkeit von 99,9% und zur Nebenzeit von 99% für alle Operationen der technischen Schnittstellen aufweisen.

    Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.

    Der Anschluss an das zentrale Netz muss über die Anschlussoption „redundante Anbindung“ erfolgen.
    [<=]

    Für das Zentrale Netz der TI wird als Gesamtbeitrag zu Anwendungsfällen ebenfalls eine Verfügbarkeit von mindestens 99,9% angestrebt. Da pro Anwendungsfall mehrere Ende-zu-Ende-Verbindungen über das Netz benötigt werden, muss eine entsprechend höhere Verfügbarkeit für Ende-zu-Ende-Verbindungen auf Netzwerkebene verlangt werden.

    GS-A_4156 - Performance – zentrales Netz – Verfügbarkeit – Anschlussoption „Hohe Verfügbarkeit“

    Das Zentrale Netz der TI MUSS die Anschlussoption „redundante Anbindung“ bereitstellen und eine Verfügbarkeit über alle IP-Verbindungen zwischen allen sicheren zentralen Zugangspunkten (SZZP) mit der Anschlussoption „redundante Anbindung“ angeschlossenen Produkttypen der TI von 99,98% im Mittel über die Hauptzeiten und von 99% im Mittel über die Nebenzeiten aufweisen.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.
    [<=]

    GS-A_4353 - Performance – zentrales Netz – Verfügbarkeit – Anschlussoption „Niedrige Verfügbarkeit“

    Das Zentrale Netz der TI MUSS die Anschlussoption „einfache Anbindung“ bereitstellen und eine Verfügbarkeit über alle IP-Verbindungen zwischen sicheren zentralen Zugangspunkten (SZZP) der angeschlossenen Produkttypen der TI von 99,8% im Mittel über die Hauptzeiten und von 99% im Mittel über die Nebenzeiten aufweisen, bei denen mindestens ein Zugangspunkt mit der Anschlussoption „einfache Anbindung“ angeschlossen ist.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage. [<=]

    A_14738 - Performance – zentrales Netz – Verfügbarkeit – SZZP-light, Anschlussvariante „redundante Anbindung“

    Das Zentrale Netz der TI MUSS für den Anschlusstyp SZZP-light die Anschlussvariante „redundante Anbindung“ bereitstellen und in dieser Variante eine Verfügbarkeit über alle Komponenten des SZZP-light Anschlusses von 99,98% im Mittel über die Hauptzeiten und von 99% im Mittel über die Nebenzeiten aufweisen. Das Transportnetz Internet ist von der Verfügbarkeit ausgenommen.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage. [<=]

    A_14739 - Performance – zentrales Netz – Verfügbarkeit – SZZP-light, Anschlussoption „einfache Anbindung“

    Das Zentrale Netz der TI MUSS für den Anschlusstyp SZZP-light die Anschlussvariante „einfache Anbindung“  bereitstellen und in dieser Variante eine Verfügbarkeit über alle Komponenten des SZZP-light Anschlusses von 99,8% im Mittel über die Hauptzeiten und von 99% im Mittel über die Nebenzeiten aufweisen. Das Transportnetz Internet ist von der Verfügbarkeit ausgenommen.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage. [<=]

    GS-A_5028 - Performance – zentrale Dienste – Verfügbarkeit Produktivbetrieb

    Die Produkttypen Namensdienst, Sicherheitsgateway Bestandsnetze, VPN-Zugangsdienst, OCSP-Proxy, TSP-X.509QES (Komponente OCSP-Responder), TSP-X.509nonQES (Komponente OCSP-Responder /CRL-Dienst und Komponente Provisioning/Revocation), Verzeichnisdienst, Service Monitoring, Störungsampel, Signaturdienst und das Zentrale Netz der TI MÜSSEN perspektivisch in der Produktivphase eine Verfügbarkeit zwischen 99,9% und 99,99% anbieten können.

    [<=]

    GS-A_5523 - Performance – zentrale Dienste – Redundanzlösung

    Anbieter von Diensten der TI, die zur Erfüllung der geforderten Verfügbarkeit eine Redundanzlösung einsetzen, MÜSSEN die Funktionsfähigkeit der Redundanzlösung in eigenverantwortlichen Tests nachweisen und die Funktionsweise der Redundanzlösung hinreichend detailliert beschreiben, so dass, anhand der Beschreibung, Testfälle zum Test der Redundanzlösung entwickelt werden können.

    [<=]

    A_20570 - Performance – Standortübergreifende Redundanz

    Der Anbieter MUSS zur Erfüllung der geforderten Verfügbarkeit eine standortübergreifende Redundanzlösung einsetzen. Dazu MUSS der Anbieter bei der Inbetriebnahme die Funktionsfähigkeit der standortübergreifende Redundanz eigenverantwortlich nachweisen und die Funktionsweise der standortübergreifende Redundanzlösung hinreichend detailliert beschreiben. Jeder Standort MUSS dabei die Performancevorgaben allein erfüllen.
    [<=]

    A_20569 - Performance – Standortredundanz

    Der Anbieter MUSS zur Erfüllung der geforderten Verfügbarkeit eine Standortredundanzlösung einsetzen. Dazu MUSS der Anbieter bei der Inbetriebnahme die Funktionsfähigkeit der Standortredundanz eigenverantwortlich nachweisen und die Funktionsweise der Standortredundanzlösung hinreichend detailliert beschreiben.. [<=]

    Am selben Standort wird die netzwerktechnische Anbindung zu einer Instanz eines mehrfach ausgeprägten Produktes getrennt. Die Last muss von den anderen, verbliebenen Instanzen übernommen werden, ohne Fehlermeldungen. Der Standort muss dabei die Performancevorgaben ohne diese eine getrennte Instanz weiterhin erfüllen.

    GS-A_4145 - Performance – zentrale Dienste – Robustheit gegenüber Lastspitzen

    Die Produkttypen der zentralen Zone der TI-Plattform MÜSSEN bei Lastspitzen oberhalb der für den Produkttypen definierten Spitzenlasten verfügbar bleiben.
    [<=]


    Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der Produkttyp abweisen oder langsamer bearbeiten. Es wird nur Robustheit gegenüber im Feld praktisch möglichen Lastspitzen erwartet.

    Ein wesentlicher Aspekt beim bundesweiten Rollout ist die Skalierung der Zahl der ausgestatteten und eingebundenen Leistungserbringer. Entsprechend müssen die zentralen Dienste skalieren.

    GS-A_3055 - Performance – zentrale Dienste – Skalierbarkeit (Anbieter)

    Anbieter für Produkttypen der zentralen Zone der TI-Plattform MÜSSEN für ihren Produkttypen, nachvollziehbar darstellen, wie die für ihren Produkttyp erforderliche Skalierung bis zum vollständigen bundesweiten Rollout erreicht werden kann.

    [<=]

    GS-A_5073 - Performance – Intermediär VSDM – Skalierbarkeit

    Anbieter für den VSDM Intermediär MÜSSEN für ihren Produkttypen nachvollziehbar darstellen, wie die für ihren Produkttyp erforderliche Skalierung bis zum vollständigen bundesweiten Rollout erreicht werden kann.

    [<=]

    GS-A_5134 - Performance – KOM-LE-Fachdienst – Skalierbarkeit

    Anbieter für den KOM-LE-Fachdienst MÜSSEN für ihren Produkttypen nachvollziehbar darstellen, wie die für ihren Produkttyp erforderliche Skalierung bis zum vollständigen bundesweiten Rollout erreicht werden kann.

    [<=]

    GS-A_3058 - Performance – zentrale Dienste – lineare Skalierbarkeit

    Die Produkttypen der zentralen Zone der TI-Plattform SOLLEN möglichst linear skalierbar sein. Diese Skalierbarkeit ist durch den Anbieter zu dokumentieren.

    [<=]

    TLS-Verbindungsaufbau

    GS-A_5331 - Performance – zentrale Dienste – TLS-Handshake

    Die Produkttypen der zentralen Zone der TI-Plattform, zu denen der Konnektor TLS-Verbindungen aufbaut, MÜSSEN bei jedem TLS-Handshake die von ihnen in Summe verursachten Zeiten im Fall einseitiger Authentisierung unter 0,5 sec und im Fall beidseitiger Authentisierung unter 1,0 sec halten. Die Anforderung gilt unabhängig davon, ob sie als TLS-Server oder TLS-Client agieren. Etwaige Zeiten für OCSP-Aufrufe werden nur dann in der Summe der verursachten Zeiten mitgezählt, wenn sie vermeidbar sind.

    [<=]

    5.2.1 Produkttyp Verzeichnisdienst

    GS-A_5135 - Performance – Verzeichnisdienst – Bearbeitungszeit unter Last

    Der Produkttyp Verzeichnisdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Verzeichnisdienst unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.

    [<=]

    Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4155], [GS-A_5028].


    Tabelle 52: Tab_gemSpec_Perf_Verzeichnisdienst: Last- u. Bearbeitungszeitvorgaben

    Schnittstellenoperation
    (Basisdienste)
    Lastvorgaben
    Bearbeitungszeitvorgaben
    Spitzenlast
    [1/sec]
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    I_Directory_Query
     
     
    search_Directory_Entry
    1000
    1000
    1250
    I_Directory_Maintenance
     
     
    add_Directory_Entry
    50
    1000
    1250
     
    read_Directory_Entry
    50
    1000
    1250
     
    modify_Directory_Entry
    50
    1000
    1250
     
    delete_Directory_Entry
    50
    1000
    1250
    I_Directory_Application_Maintenance
     
     
    add_Directory_FA_Attributes
    50
    1000
    1250
     
    delete_Directory_FA_Attributes
    50
    1000
    1250
     
    modify_Directory_FA_Attributes
    50
    1000
    1250

    5.2.2 Produkttyp Konfigurationsdienst

    GS-A_4157 - Performance – Konfigurationsdienst – Bearbeitungszeit unter Last

    Der Produkttyp Konfigurationsdienst MUSS parallel die Last- und Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_Konfigurationsdienst für die Operationen list_Updates und get_Updates(Download-Software-Pakete) erlauben. Für den Anwendungsfall get_Updates(Download-Software-Pakete) muss die Anzahl der geforderten parallelen Downloads garantiert werden. Die Download-Dateien müssen während des Download-Transports komprimiert sein.

    [<=]

    GS-A_4853 - Performance – Konfigurationsdienst – Verfügbarkeit

    Der Konfigurationsdienst MUSS eine Verfügbarkeit von 99 % haben. In der Hauptzeit MUSS zusätzlich die Ausfallzeit auf maximal eine Stunde pro Tag limitiert sein. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.
    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.
    [<=]

    Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

    Tabelle 53: Tab_gemSpec_Perf_Konfigurationsdienst: Last- u. Bearbeitungszeitvorgaben

    Schnittstellenoperation
    Last
    Bearbeitungszeit
    Spitzenlast
    [1/s]
    Datenmenge
    [kByte]
    Parallele
    Downloads
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    Infrastrukturdienste
     
     
     
     
     
     
    I_KSRS_Download
     
     
     
     
     
     
     
    list_Updates
    7
    10
     
    100
    300
     
     
    get_Updates
    (Download-Software-Pakete)
     
    bis zu
    1500000
    pro KSR
    Download
    Cache Server

    1000 mit
    in Summe
    1 Gbit/sec
     
     

    5.2.3 Produkttypen der PKI – TSL-Dienst

    Der TSL-Dienst stellt drei technische Schnittstellen zur Verfügung: I_TSL_Download, I_OCSP_Status_Information und I_BNetzA_VL_Download.

    GS-A_4854 - Performance – TSL-Dienst – Last und Parallele Downloads

    Der Produkttyp TSL-Dienst MUSS die Vorgaben an Last und Anzahl der parallelen Downloads aus Tab_gemSpec_Perf_TSL-Dienst garantieren. Die Download-Dateien müssen während des Download-Transports komprimiert sein, wobei ein Komprimierungsverfahren für alle Dateitypen zu verwenden ist, das Textdateien mindestens um einen Faktor 3 komprimiert.

    [<=]

    Die Anforderungen bzgl. Last und Bearbeitungszeit an die Schnittstelle I_OCSP_Status_Information stellt Kapitel 4.2.4.

    GS-A_4158 - Performance – TSL-Dienst – Verfügbarkeit

    Der TSL-Dienst MUSS eine Verfügbarkeit von 99 % haben. In der Hauptzeit MUSS zusätzlich die Ausfallzeit auf maximal eine Stunde pro Tag limitiert sein. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.

    [<=]

    Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4159].

    Tabelle 54: Tab_gemSpec_Perf_TSL-Dienst: Lastvorgaben

    Schnittstellenoperation
    Last
    Datenmenge
    [kByte]
    Parallele
    Downloads
    Infrastrukturdienste
     
    I_TSL_Download
     
     
    download_TSL (TI)
    200 (*)
    60 mit in Summe 60 Mbit/sec
    download_TSL (Internet) 200 (*) 5 mit in Summe 5 Mbit/sec


    get_Hash
    0,1
    50 mit in Summe 1 Mbit/sec
     
    I_BNetzA_VL_Download
     
     
    download_VL
    6000 (**)
    250 mit in Summe 250 Mbit/sec
     
     
    get_Hash
    0,1
    10 mit in Summe 1 Mbit/sec

     (*) Die Größe der TSL wird mit maximal 500 kByte angenommen. Für den Transport wird angenommen, dass sie auf 130 kByte komprimiert ist.

    (**) Die Größe der BNetzA_VL wird mit maximal 6000 kByte angenommen. Für den Transport wird angenommen, dass sie auf 2000 kByte komprimiert ist.

    5.2.4 PKI-Komponenten – OCSP-Responder / CRL-Dienst

    Die Schnittstelle I_OCSP_Status_Information mit der Operation check_Revocation_Status zur Abfrage des Sperrstatus von X.509-Zertifikaten stellen die Produkttypen OCSP-Proxy, TSP-X.509QES und TSP-X.509nonQES bereit.

    Tabelle 55: Tab_gemSpec_Perf_OCSP_Responder – Last- und Bearbeitungszeitvorgaben

    Produkttyp
    Funktion
    Spitzenlast
    [1/sec]
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    OCSP-Resp.
    TSP-X.509QES
    Prüfung von HBA-Zertifkaten
    aus der TI
    (C.HP.QES): EE-Zert
    500
    2.000
    2.400
    Prüfung von HBA-Zertifkaten
    aus dem Internet
    (C.HP.QES): EE-Zert
    30
    OCSP-Resp.
    TSP-X.509nonQES
    Prüfung von eGK-Zertifikaten
    aus der TI
    (C.CH.AUT)
    1.000
    1.000
    1.300
    Prüfung von Zertifikaten
    der alternativen Versichertenidentitäten
    aus der TI
    (C.CH.AUT_ALT)
    80
    Prüfung von SMC-B-Zertifikaten
    aus der TI
    (C.HCI.OSIG)
    1100
    Prüfung von SMC-B-Zertifikaten
    aus dem Internet
    (C.HCI.OSIG)
    30
    Prüfung von HBA-Zertifikaten
    aus der TI
    (C.HP.ENC)
    310
    Prüfung von HBA-Zertifikaten
    aus dem Internet
    (C.HP.ENC)
    15
    Prüfung von SMC-B Zertifikaten
    aus der TI
    (C.HCI.ENC)
    310
    Prüfung von SMC-B Zertifikaten
    aus dem Internet
    (C.HCI.ENC)
    15
    Prüfung von Konnektor-Zertifikaten
    aus der TI
    (gSMC-K, C.NK.VPN)
    110
    Prüfung von SMC-B-Zertifikaten
    aus der TI
    (C.HCI.AUT)

    385
    Prüfung von SMC-B-Zertifikaten
    aus dem Internet
    (C.HCI.AUT)
    30
    Prüfung von HBA-Zertifikaten
    aus der TI
    (C.HP.AUT)
    -
    Prüfung von HBA-Zertifikaten
    aus dem Internet
    (C.HP.AUT)
    30
    Prüfung von TLS Zertifikaten der 
    zentralen Dienste
    aus der TI
    (C.ZD.TLS)
    110
    Prüfung von TLS Zertifikaten der
    Fachdienste aus der TI  (C.FD.TLS)
    500
    Prüfung von TLS-Zertifikaten für weitere Anwendungen 300
    OCSP-Resp.
    TSL-Dienst
    Prüfung des TSL-Signerzertifikats
    aus der TI
    45
    1.000
    1.300
    OCSP-Resp. 
    VPNK-CA Internet
    Prüfung eines VPN-Konzentratorzertifikats durch einen Konnektor über das Internet 45 1.000 1.300
    OCSP-Resp.
    gematik-Root-CA
    Prüfung von HBA-Zertifikaten
    aus dem Internet
    (C.HP.ENC): CA-Zert
    15
    1.000
    1.300
    Prüfung von HBA-Zertifikaten
    aus dem Internet
    (C.HP.AUT): CA-Zert
    30
    Prüfung von SMC-B-Zertifikaten
    aus dem Internet
    (C.HCI.ENC): CA-Zert
    15
    Prüfung von SMC-B-Zertifikaten
    aus dem Internet
    (C.HCI.AUT): CA-Zert
    30
    Prüfung von SMC-B-Zertifikaten
    aus dem Internet
    Root-CA-Zert
    45

     

    GS-A_5550 - Performance – OCSP Responder – Grundlast

    Die Produkttypen TSP-X.509 QES, TSP-X.509 nonQES, TSL-Dienst und gematik-Root-CA MÜSSEN die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_OCSP_Responder unter einer Last von 5 Anfragen pro Sekunde erfüllen.

    [<=]

    GS-A_4159 - Performance – OCSP Responder – Bearbeitungszeiten unter Spitzenlast

    Die Produkttypen TSP-X.509 QES, TSP-X.509 nonQES, TSL-Dienst und gematik-Root-CA MÜSSEN die Bearbeitungszeitvorgaben unter der für alle Funktionen parallel anliegenden Spitzenlast dauerhaft erfüllen.

    Die dabei geltende Spitzenlast pro Funktion wird aus Tabelle Tab_gemSpec_Perf_OCSP_Responder wie folgt abgeleitet:

    [<=]

    Für Neuzulassungen wird generell die Erfassung und Lieferung von Performance-Rohdaten präferiert, da die Sendung aggregierter Performance-Daten an die Störungsampel (bzw. Service Monitoring) und die Lieferung monatlicher Performance-Reports zukünftig zugunsten von Rohdatenlieferungen entfallen wird.

    A_14502 - Performance – CRL-Dienst – Last und Parallele Downloads

    Der TSP-X.509 nonQES für Komponenten MUSS die Vorgaben an Last und Anzahl der parallelen Downloads aus Tab_gemSpec_Perf_CRL-Dienst garantieren. [<=]

    Tabelle 56: Tab_gemSpec_Perf_CRL-Dienst: Lastvorgaben

    Schnittstellenoperation
    Last
    Datenmenge
    [kByte]
    Parallele
    Downloads
    Infrastrukturdienste
     
    I_CRL_Download
     
     
    download_CRL
    10 (*)
    2 mit in Summe 2 Mbit/sec

    Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4155], [GS-A_5028].

    5.2.5 Produkttyp TSP-X.509nonQES (Komp) - Provisioning/Revocation

    A_18013 - Performance – TSP – Provisioning/Revocation – Bearbeitungszeit

    Der Produkttyp TSP-X.509nonQES der Komponenten-PKI MUSS die Bearbeitungszeitvorgaben aus Tab_gemSpec_Perf_TSP_Provisioning_Revocation bei den dort angegebenen parallelen Requests erfüllen. [<=]

    Tabelle 57: Tab_gemSpec_Perf_TSP_Provisioning_Revocation: Bearbeitungszeitvorgaben

    Schnittstellenoperation
    (Basisdienste)
    Bearbeitungszeitvorgaben
    Anzahl
    paralleler Requests
    Mittelwert
    [sec]
    I_Cert_Provisioning


    provide_Certificate (Web-Benutzerschnittstelle)
    1
    5

    provide_Certificate (SOAP) – bezogen auf 100 Zertifikatsbeantragungen pro SOAP-Request
    3
    30

    provide_Certificate (CMP) – bezogen auf 100 Zertifikatsbeantragungen pro CMP-Request
    3
    30
    I_Cert_Revocation


    revoke_Certificate (Web-Benutzerschnittstelle)
    1
    5

    revoke_Certificate (SOAP) – bezogen auf 100 Zertifikatsbeantragungen pro SOAP-Request
    3
    30

    revoke_Certificate (CMP) – bezogen auf 100 Zertifikatsbeantragungen pro CMP-Request
    3
    30

    Weitere Anforderungen: [GS-A_4146], [GS-A_4147], [GS-A_4149], [GS-A_4155], [GS-A_5028].

    5.2.6 Produkttyp Störungsampel

    GS-A_4161 - Performance – Störungsampel – Durchsatz

    Der Produkttyp Störungsampel MUSS die Durchsatzvorgaben aus Tab_gemSpec_Perf_Störungsampel erfüllen.
    [<=]


    Tabelle 58: Tab_gemSpec_Perf_Störungsampel – Lastvorgaben

    Schnittstellenoperation
    Last
    Spitzenlast
    Datenmenge
    [1/sec]
    [kByte]
    Infrastrukturdienste
     
     
    I_Monitoring_Update
     
     
     
    update_Information
    2
    4
     
    I_Monitoring_Read
     
     
     
    read_Information
     
     


    Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4155], [GS-A_5028].

    5.2.7 Produkttyp Service Monitoring

    Für den Produkttypen Service Monitoring gelten folgende Anforderungen: [GS-A_4155], [GS-A_5028], [GS-A_3055],[GS-A_3058], [GS-A_4145].

    5.2.8 Produkttyp Namensdienst

    GS-A_4162 - Performance – Namensdienst – Bearbeitungszeit unter Last

    Der Produkttyp Namensdienst und der Produkttyp VPN-Zugangsdienst MÜSSEN die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Namensdienst unter der für alle Funktionen parallel anliegenden Spitzenlast an den DNS-Schnittstellen erfüllen.

    [<=]

    Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145],
    [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149], [GS-A_4155], [GS-A_5028].

    Tabelle 59: Tab_gemSpec_Perf_Namensdienst: Last- u. Bearbeitungszeitvorgaben

    Schnittstellenoperation
    Lastvorgaben
    Bearbeitungszeitvorgaben
    Spitzenlast
    [1/sec]
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    Infrastrukturdienste
     
     
     
    I_DNS_Service_Localization
     
     
     
    get_Service_Location
    200
    60
    120
     
    I_DNS_Name_Resolution
     
     
     
    get_IP_Address
    200
    30
    70
     
     
    get_FQDN
    400
    30
    70

    5.2.9 Produkttyp Zeitdienst

    Als NTP-Clients, die den Zeitdienst abfragen, können neben den Hauptinstanzen der zentralen Dienste der TI-Plattform auch Switches, Router und Firewalls in Aktion treten. Es wird von maximal 1000 NTP-Clients ausgegangen. Die Clients fragen die Server nicht öfter als alle 64 Sekunden ab. Bei stabiler Zeitsynchronisation wird ein NTP-Client das Abfrage-Intervall auf bis zu 1024 Sekunden vergrößern. Daher wird bzgl. Skalierbarkeit nur die Fähigkeit gefordert, 20 Anfragen pro Sekunde (>1000/64/sec) verarbeiten zu können.

    GS-A_4163 - Performance – Zeitdienst – Durchsatz

    Die Stratum 1 NTP Server des Produkttyps Zeitdienst und der Stratum 2 NTP Server des Produkttyps VPN-Zugangsdienst MÜSSEN jeweils mindestens eine Spitzenlast von 200 NTP Anfragen pro Sekunde verarbeiten können.

    [<=]

    GS-A_4165 - Performance – Zeitdienst – Verfügbarkeit

    Der Produkttyp Zeitdienst und der Produkttyp VPN-Zugangsdienst MÜSSEN jeweils eine Verfügbarkeit von 99 % mit einer maximalen Ausfalldauer von 24 Stunden für die Schnittstelle I_NTP_Time_Information haben.

    Der Zeitdienst gilt als nicht verfügbar, wenn folgende Störungen auf mindestens zwei Stratum 1 NTP Server des Zeitdienstes auftreten:

    [<=]

    Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

    5.2.10 Produkttyp Zentrales Netz der TI

    Das zentrale Netz der TI dient der performanten Kommunikation zwischen VPN-Zugangsdiensten, zentralen Diensten und fachanwendungsspezifischen Diensten.

    Bzgl. Verfügbarkeit wird dies durch die Anforderungen [GS-A_4156] und [GS-A_4353] an das zentrale Netz der TI und die Anforderung [GS-A_4155] an die zentralen Dienste für den Anschluss an das zentrale Netz erreicht.

    Abbildung 9 skizziert die Punkte im Netzwerk, für die Spitzenlastvorgaben gestellt werden. Bzgl. Last und Bearbeitungszeiten werden folgende Anforderungen gestellt:

    GS-A_4166 - Performance – Zentrales Netz – Durchsatz

    Das Zentrale Netz der TI MUSS die Netzwerkverbindungen so auslegen, dass die an den SZZP und SZZP-light Anschlüssen vereinbarte Bandbreite nutzbar ist und jederzeit über das zentrale Netz transportiert werden kann.
    [<=]

    GS-A_4167 - Performance – Zentrales Netz – Roundtrip Time

    Das Zentrale Netz der TI-Plattform MUSS eine RoundtripTime für IP-Pakete von höchstens 30 msec im Mittel über alle Verbindungen von Anschlusspunkt zu Anschlusspunkt aufweisen.

    [<=]

    GS-A_4347 - Performance – Zentrales Netz – Paketverlustrate

    Das Zentrale Netz der TI-Plattform MUSS eine Verlustrate für IP-Pakete von höchstens 0,1 % im Mittel über alle Verbindungen von Anschlusspunkt zu Anschlusspunkt aufweisen.

    [<=]

    Bzgl. Robustheit gegenüber Lastspitzen ist die Anforderung [GS-A_4145] zu erfüllen. Detailregelungen zu Überlastsituationen erfolgen in [gemSpec_Net].

    Anforderungen zum Reporting regeln die folgenden Anforderungen übergreifend: [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

    Wie die Volumenmessungen zu erfolgen haben, regeln die nachfolgenden Anforderungen. Zur Topologie siehe hierzu [gemKPT_Arch_TIP], Abbildung „Netzwerktopologie der TI“.

    GS-A_5014 - Performance – Zentrales Netz – Volumenmessung im SZZP

    Das Zentrale Netz der TI-Plattform MUSS an seinen Sicheren Zentralen Zugangspunkten (SZZPs) und an SZZP-light das Volumen der übertragenen Daten erfassen.

    An SZZPs, die VPN Zugangsdienste anschließen, MUSS das Volumen getrennt nach den einzelnen VPN-Zugangsdienstinstanzen und jeweils nach der Richtung vom und zum VPN-Zugangsdienst erfasst werden.

    An SZZPs, die Zentrale Dienste der TI-Plattform oder fachanwendungsspezifische Dienste anschließen, MUSS das Volumen getrennt nach Dienstinstanz und jeweils nach der Richtung vom und zum Dienst erfasst werden. Dabei meint Dienstinstanz eine Aufschlüsselung nach Produktinstanz und Anbieter. Abweichend von dieser generellen Regelung ist für die VSDM Dienstinstanzen keine Aufschlüsselung nach Produktinstanz und Anbieter gefordert, sondern nur eine Aufschlüsselung nach SZZPs und Richtung.

    An SZZP-light, die WANDA Smart an das zentrale Netz der TI anschließen, MUSS das Volumen getrennt nach Dienstinstanz und jeweils nach der Richtung vom und zum Dienst erfasst werden. Dabei meint Dienstinstanz eine Aufschlüsselung nach Produktinstanz und Anbieter.

    An SZZPs, die Sicherheitsgateways Bestandsnetze anschließen, MUSS das Volumen getrennt nach den einzelnen Instanzen der Sicherheitsgateways Bestandsnetze und jeweils nach der Richtung von und zur Instanz des Sicherheitsgateways Bestandsnetze erfasst werden.
    [<=]

    Die Aufschlüsselung der Volumenflüsse im SZZP nach Dienstinstanzen erfolgt über die in [gemSpec_Net] geregelte Zuordnung von IP-Adressen zu Produktinstanz und Anbieter.

    Weitere Anforderungen: [GS-A_3055], [GS-A_3058], [GS-A_4156], [GS-A_4353], [GS-A_5028].


    Hinweis: Die Spitzenlasten beziehen sich auf die Summe aller Instanzen pro Produkttyp.

    Abbildung 9: Netzwerktopologie – Punkte mit Lastvorgaben (orange)

    Tabelle 60: Tab_gemSpec_Perf_Netzlast_1 Spitzenlasten am VPN-Zugangsdienst (Punkt 1)


    Datenstrom
    Zusammensetzung
     
    Spitzenlast
    Mbit/sec
    VPN-Zugangsdienst
    zur
    zentralen Zone
    Summe
     
    3.417
    Bestandsnetz
     
    150
    VSDM Intermediär
     
    8
    OCSP-Responder + OCSP-Proxy
     
    8
    KOM-LE-Fachdienst
     
    3.248
    Verzeichnisdienst
     
    3
    zentrale Zone
    zu
    VPN-Zugangsdienst
    Summe
     
    4.016
    KSR (Download Softwarepakete)
     
    100
    Bestandsnetz
     
    150
    OCSP-Responder + OCSP-Proxy
     
    104
    VSDM Intermediär
     
    13
    TSL-Dienst (Download TSL, BNetzA_VL)
     
    360
    KOM-LE-Fachdienst
     
    3.248
    Verzeichnisdienst
     
    41

    5.2.11 Produkttyp VPN-Zugangsdienst

    [verschoben in 3.x.1 Leistungsanforderungen VPN-Zugangsdienst]

    5.2.12 Produkttyp Sicherheitsgateway Bestandsnetze

    An der Schnittstelle I_Secure_Access_Bestandsnetz des Sicherheitsgateways Bestandnetze gelten folgende Performance-Anforderungen:

    [GS-A_3055], [GS-A_3058], [GS-A_4145], [GS-A_4146], [GS-A_4147], [A_14936], [GS-A_4149], [GS-A_4155].

    5.2.13 Produkttyp Signaturdienst

    A_18018 - Performance - Signaturdienst - Spitzenlastvorgaben

    Der Anbieter Signaturdienst  MUSS das System so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß Tabelle Tab_gemSpec_Perf_Signaturdienst: Last- und Bearbeitungszeitvorgaben erfüllt wird. Die Lastvorgabe aus dieser Tabelle bezieht sich auf die Anzahl der gesetzlich Versicherten.
    [<=]

    Zur Erläuterung der Anforderung [A_18018]:

    Der Anbieter muss für seinen Marktanteil das System so dimensionieren, dass die Lastvorgaben am Signaturdienst eingehalten werden.
    Beispielrechnung: Für ein Marktanteil von 20% und eine Lastvorgabe von 100 Anfragen pro Sekunde muss der Signaturdienst mindestens 20 Anfragen pro Sekunde an die nachgelagerten Komponenten weiterleiten können.
    Beispielrechnung: Bei einem Marktanteil von 20% muss für die Operation "I_Remote_Sign_Operations:sign_Data" eine Lastvorgabe von mindestens 20 Anfragen pro Sekunde eingehalten werden (20% von 100 Anfragen pro Sekunde).

    Tabelle 61: Tab_gemSpec_Perf_Signaturdienst: Last- u. Bearbeitungszeitvorgaben

    Schnittstellenoperation
    (Basisdienste)
    Lastvorgaben
    Bearbeitungszeitvorgaben
    Spitzenlast
    [1/sec]
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    I_Remote_Sign_Operations
     
     
    sign_Data
    100
    150
    240

    A_17802 - Performance – Signaturdienst – Bearbeitungszeit unter Last

    Der Produkttyp Signaturdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Signaturdienst erfüllen.

    [<=]

    A_18178 - Performance - Signaturdienst - Erfassung von Rohdaten

    Der Produkttyp Signaturdienst MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_SigD" erfassen und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
    [<=]

    A_17985 - Performance - Signaturdienst - Lieferung von Rohdaten

    Der Anbieter Signaturdienst MUSS in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance-Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678]  liefern. Voreingestellt für das Zeitintervall ist täglich.
    [<=]

    Ebenfalls gelten folgende Anforderungen:  [GS-A_4155], [GS-A_5028], [GS-A_3055],[GS-A_3058], [GS-A_4145].

    5.2.14 Produkttyp Schlüsselgenerierungsdienst

    Für den Schlüsselgenerierungsdienst der zentralen Zone der TI-Plattform und dem Schlüsselgenerierungsdienst am Fachdienst gelten folgende Anforderungen:

    A_17841 - Performance – Schlüsselgenerierungsdienst – zentral - Bearbeitungszeit unter Last

    Der Produkttyp Schlüsselgenerierungsdienst der zentralen Zone der TI-Plattform MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben" unter der für alle Funktionen parallel anliegenden Spitzenlast erfüllen.

    Tabelle 62: Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben

    Schnittstellenoperationen
    Lastvorgaben
    Bearbeitungszeitvorgaben
    Spitzenlast
    [1/sec]
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    GetPublicKey
    100
    100
    174
    GetAuthenticationToken und
    KeyDerivation

    jeweils
    100
    in Summe
    3700
    in Summe
    4147
    [<=]

    A_18179 - Performance - Schlüsselgenerierungsdienst - zentral - Erfassung von Rohdaten

    Der Produkttyp Schlüsselgenerierungsdienst der zentralen Zone der TI-Plattform MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_SGD" erfassen und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
    [<=]

    A_17983 - Performance - Schlüsselgenerierungsdienst - zentral - Lieferung von Rohdaten

    Der Anbieter Schlüsselgenerierungsdienst der zentralen Zone der TI-Plattform MUSS in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance-Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678]  liefern. Voreingestellt für das Zeitintervall ist 5 Minuten.
    [<=]

    A_18251 - Performance - Schlüsselgenerierungsdienst - zentral - Verfügbarkeit

    Der Produkttyp Schlüsselgenerierungsdienst der zentralen Zone der TI MUSS eine Verfügbarkeit von 99,98 in der Haupt- und Nebenzeit für alle Operationen der technischen Schnittstellen aufweisen.

    Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.

    Der Anschluss an das zentrale Netz muss über die Anschlussoption „Hohe Verfügbarkeit“ erfolgen. [<=]

    Ebenfalls gelten folgende Anforderungen an den Schlüsselgenerierungsdienst der zentralen Zone der TI-Plattform: 

    [GS-A_3055],[GS-A_3058],[GS-A_4145].

    A_17967 - Performance – Schlüsselgenerierungsdienst – am FD - Spitzenlastvorgaben

    Der Anbieter Schlüsselgenerierungsdienst am FD MUSS das System so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß Tabelle "Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben" erfüllt wird.

    [<=]

    Zur Erläuterung der Afo [A_17967]:

    Der Anbieter muss die Anzahl seiner Nutzer kennen und sein System mindestens so dimensionieren, dass die Lastvorgaben eingehalten werden. Beispielrechnung: Für 12,57 Mio. Nutzer (etwa 17,95% Marktanteil) muss für die Operation "GetPublicKey" eine Lastvorgabe von mindestens 18 Anfragen pro Sekunde eingehalten werden (17,95% von 100 Anfragen pro Sekunde).

    A_17977 - Performance - Schlüsselgenerierungsdienst - am FD - Bearbeitungszeit unter Last

    Der Schlüsselgenerierungsdienst am FD MUSS die Bearbeitungszeitvorgaben unter Last für die Schnittstellenoperationen aus Tabelle "Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben" erfüllen.

    [<=]

    A_17975 - Performance - Schlüsselgenerierungsdienst - am FD - Robustheit gegenüber Lastspitzen

    Der Schlüsselgenerierungsdienst am FD MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben" verfügbar bleiben.

    [<=]

    Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der Signaturdienst vorübergehend abweisen. Vom System angenommene Anfragen müssen weiterhin innerhalb der Performancevorgaben verarbeitet werden. Der Anbieter hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.

    A_17978 - Performance - Schlüsselgenerierungsdienst - am FD - Skalierung

    Der Anbieter Schlüsselgenerierungsdienst am FD MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird.
    [<=]

    A_17979 - Performance - Schlüsselgenerierungsdienst - am FD - Verfügbarkeit

    Der Anbieter Schlüsselgenerierungsdienst am FD MUSS zur Hauptzeit eine Verfügbarkeit von 99,9% und zur Nebenzeit von 99% für alle Operationen der technischen Schnittstellen aufweisen.

    Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.

    Die Anschlüsse aller Standorte an das zentrale Netz MÜSSEN über die Anschlussoption "Hohe Verfügbarkeit" erfolgen.

    [<=]

    A_20518 - Performance - Schlüsselgenerierungsdienst - am FD - Spitzenlastvorgaben TU

    Der Anbieter Schlüsselgenerierungsdienst am FD MUSS in der TU-Umgebung 5% der für die in Tabelle "Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben" genannten Operationen geltenden Spitzenlastvorgaben unter Einhaltung der mittleren Bearbeitungszeiten erfüllen.

    Ist der Marktanteil kleiner als 5% MUSS der Anbieter Schlüsselgenerierungsdienst am FD nur den entsprechenden Prozentwert seines Marktanteils in der TU umsetzen. Der Prozentwert MUSS mit angegeben werden.
    [<=]

    A_18180 - Performance - Schlüsselgenerierungsdienst - am FD - Erfassung von Rohdaten

    Der Schlüsselgenerierungsdienst am FD MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_SGD" erfassen und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
    [<=]

    A_17981 - Performance - Schlüsselgenerierungsdienst - am FD - Lieferung von Rohdaten

    Der Anbieter Schlüsselgenerierungsdienst am FD MUSS in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678] liefern. Voreingestellt für das Zeitintervall ist täglich.
    [<=]

    5.2.15 Produkttyp IdP-Dienst

    [verschoben in 3.x.1.3 Performancevorgaben IDP-Dienste]

    5.3 Produkttypen VSDM

    5.3.1 Produkttyp VSDM Intermediär

    GS-A_5029-01 - Performance – VSDM Intermediär – Bearbeitungszeit unter Last

    Der Produkttyp Intermediär MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_Intermediaer erfüllen. Die dabei zu unterstützende Spitzenlast pro Sekunde berechnet sich aus der durch die VSDM-Intermediär-Instanz maximal zu unterstützende Anzahl an Leistungserbringern in Tausend multipliziert mit dem Faktor 5,35.

    Die Vorgaben beziehen sich auf die einzelnen Request-Response-Zyklen. Sie beinhalten die Bearbeitungszeitbeiträge aus Request und Response in Summe. Es wird davon ausgegangen, dass der Intermediär eingeschwungen ist und z. B. Lokalisierungsanfragen lokal zwischengespeichert sind sowie Verbindungen nicht neu ausgehandelt werden.

    Für die Zulassung ist der Nachweis bei einer Last von 100 Anfragen pro Sekunde zu erbringen.

    Tabelle 63 Tab_gemSpec_Perf_Intermediaer: Bearbeitungszeitvorgaben

    Bearbeitungszeitvorgaben
    Mittelwert
    [msec]
    95%-Quantil
    [msec]
    100
    150
    [<=]

    GS-A_5030 - Performance – VSDM Intermediär – Verfügbarkeit

    Der Produkttyp Intermediär MUSS zur Hauptzeit eine Verfügbarkeit von 99,8% und zur Nebenzeit von 99% haben.

    Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
    [<=]

    A_20170 - Performance - Erfassung von Rohdaten - Intermediär VSDM

    Der Intermediär VSDM MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_Intermediär VSDM" erfassen und Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitinervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
    [<=]

    Außerdem gelten folgende Anforderungen für das Erfassen und Reporten von Performance-Kennzahlen: [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

    5.3.2 Produkttypen Fachdienste VSDM (UFS, VSDD, CMS)

    GS-A_5031 - Performance – VSDM Fachdienste – Bearbeitungszeit unter Last

    Die Produkttypen Fachdienst UFS, Fachdienst VSDD und Fachdienst CMS MÜSSEN die Bearbeitungszeitvorgaben für das 95%-Quantil unter Last aus Tab_gemSpec_Perf_VSDM_Fachdienste erfüllen. Sie SOLLEN die Bearbeitungszeitvorgaben für den Mittelwert unter Last aus Tab_gemSpec_Perf_VSDM_Fachdienste erfüllen.

    Die Bearbeitungszeiten für alle Request-Response-Zyklen eines Anwendungsfalls tragen zur Bearbeitungszeit bei. Es wird davon ausgegangen, dass die Fachdienste eingeschwungen sind, so dass Verbindungen nicht neu ausgehandelt werden.
    [<=]


    Tabelle 64: Tab_gemSpec_Perf_VSDM_Fachdienste: Last- und Bearbeitungszeitvorgaben

    Produkttypen
    Anwendungsfalldetails
    Lastvorgaben
    Bearbeitungszeitvorgaben
    Spitzenlast
    [1/sec]
    Mittelwert
    [msec]
    95%-Quantil
    [msec]
    Fachdienst
    UFS
    Bearbeitungszeiten vom Eingang der Anfrage "GetUpdateFlags" bis zum Versand der Antwort durch den Fachdienst
    1000
    235
    280
    Fachdienst
    VSDD/CMS
    Summe aller Bearbeitungszeiten aller VSDD/CMS-Anfragen (vom Empfang der Anfrage bis zum Versand der Antwort durch den Fachdienst), die zu jeweils einer Aktualisierung der eGK gehören. Die VSDD/CMS-Anfragen umfassen sowohl die Operation "PerformUpdates" als auch die anschließenden "GetNextCommandPackaged"-Operationen.
    25
    1560
    5585

    GS-A_5032 - Performance – VSDM Fachdienste – Verfügbarkeit

    Die Produkttypen Fachdienst UFS, Fachdienst VSDD und Fachdienst CMS MÜSSEN zur Hauptzeit eine Verfügbarkeit von 99,8% und zur Nebenzeit von 98,5% haben.

    Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.


    [<=]

    Die Verfügbarkeit der funktionalen Eigenschaften der Produkttypen Fachdienst UFS, Fachdienst VSDD und Fachdienst CMS wird mittels der Probes des Service Monitorings und die nicht funktionalen Eigenschaften durch Auswertung der Rohdaten ermittelt.

    Weiterhin gelten folgende Anforderungen für das Erfassen und Liefern von Rohdaten: 

    A_17268 - Performance - Erfassung von Rohdaten - Fachdienste VSDM

    Die Betreiber der Fachdienste VSDM MÜSSEN Rohdaten gemäß [Tab_gemSpec_Perf_Berichtsformat_VSDM] erfassen.

    [<=]

    A_17267 - Performance - Lieferung von Rohdaten - Fachdienste VSDM

    Die Betreiber der Fachdienste VSDM MÜSSEN in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678] liefern. Voreingestellt für das Zeitintervall ist täglich.
    [<=]

    5.4 Produkttypen KOM-LE

    5.4.1 Produkttyp KOM-LE-Clientmodul

    GS-A_5136 - Performance – KOM-LE-Clientmodul – Bearbeitungszeit unter Last

    Der Produkttyp KOM-LE-Clientmodul MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_KOMLE_Clientmodul unter der für die Anwendungsfälle parallel anliegenden Spitzenlast erfüllen. Die Lastanforderungen müssen von den Clientmodulen für die jeweilige Leistungserbringerumgebung LE-U1, LE-U2, LE-U3 oder LE-U4 erbracht werden. Das KOM-LE-Clientmodul muss diese Zeiten unter der Nebenbedingung erbringen, dass die anderen Produkttypen die Zeiten gemäß der Zerlegung der Bearbeitungszeiten in Tabelle Tab_gemSpec_Perf_KOMLE_Bearbeitungszeitbeiträge einhalten und dass die Ausführung auf einem durchschnittlichen PC erfolgt.

    [<=]

    Tabelle 65: Tab_gemSpec_Perf_KOMLE_Clientmodul: Last- und Bearbeitungszeitvorgaben

    Anwendungsfall
    Datenmenge in KB
    Spitzenlast [1/h]
    Bearbeitungszeit
    LE-U1
    LE-U2
    LE-U3
    LE-U4
    Mittelwert
    [sec]
    Empfängerdaten ermitteln
    10
    10
    37
    94
    237
    1,2
    Nachricht schützen und an KOM-LE-Fachdienst senden
    50
    200
    200
    200
    200
    8,9
    100
    10
    35
    90
    224
    12,5
    25600
    13
    13
    13
    13
    260 (*)
    Nachricht vom KOM-LE Fachdienst holen und aufbereiten
    50
    200
    200
    200
    200
    4,3
    100
    10
    35
    90
    224
    4,8
    25600
    13
    13
    13
    13
    38,5 (*)
    Aufbau sicherer Kanal vom Clientmodul zum Fachdienst
     
    34
    34
    70
    70
    3,9


    (*) In diesem besonderen Nutzungsbedarf wird von einer Transportnetzanbindung von
    16 Mbit/sec in Download-Richtung und 1024 Kbit/sec in Upload-Richtung ausgegangen.

    Tabelle 66: Tab_gemSpec_Perf_KOMLE_Bearbeitungszeitbeiträge: Zerlegung Bearbeitungszeiten

    Anwendungsfall
    Daten-
    menge
    in KB
    Bearbeitungszeitbeiträge [sec]
    Konnektor,
    Anzeige am Arbeitsplatz,
    Kartenterminal,
    Karten,
    Verzeichnis-
    dienst
    LE-
    LAN
    Zugangs-
    netz
    KOM-
    LE
    Client-
    modul
    KOM-
    LE
    Fach-
    dienst
    OCSP- Responder
    Empfängerdaten ermitteln
    10
    1,0
    0,0
    0,1
    0,0
    0,0
    0,0
    Nachricht schützen und an KOM-LE Fachdienst senden
    50
    3,3
    0,1
    3,9
    0,5
    0,0
    1,0
    100
    3,3
    0,1
    7,5
    0,5
    0,0
    1,0
    25600
    4,6
    23,5
    229,3 *
    1,0
    0,0
    1,0
    Nachricht vom KOM-LE Fachdienst holen und aufbereiten
    50
    1,2
    0,1
    0,6
    0,5
    0,0
    1,0
    100
    1,2
    0,1
    1,1
    0,5
    0,0
    1,0
    25600
    2,3
    18,8
    14,4 *
    1,0
    0,0
    1,0
    Aufbau TLS-Kanal zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst
     
    1,3
    0
    0,4
    0,1
    0,1
    2,0

    (*) In diesem besonderen Nutzungsbedarf wird von einer Transportnetzanbindung von
    16 Mbit/sec in Download-Richtung und 1024 Kbit/sec in Upload-Richtung ausgegangen.

    5.4.2 Produkttyp KOM-LE-Fachdienst

    A_20129 - Performance - KOM-LE-Fachdienst - Spitzenlastvorgaben

    Der Anbieter KOM-LE-Fachdienst MUSS das System so dimensionieren, dass für seine Nutzer der erwartete Spitzenlast gemäß "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben" erfüllt werden. Die Lastvorgabe aus dieser Tabelle bezieht sich auf die Anzahl aller KOM-LE-Teilnehmer.
    [<=]

    Zur Erläuterung der Afo [A_20129]:

    Der Anbieter muss die Anzahl seiner KOM-LE-Teilnehmer kennen und sein System mindestens so dimensionieren, dass die Lastvorgaben eingehalten werden.
    Beispielrechnung: Für 210.000 KOM-LE-Teilnhmer (siehe Tabelle "Tab_Mengengerüst: Annahmen für Modellierung") ergibt sich auf Basis von 10.000 Teilnehmern eines Anbieters eine Lastvorgabe von mindestens 8 Anfragen pro Sekunde für das senden von Mails mit einer Nachrichtengröße von 100KB. (5% von 160 Anfragen pro Sekunde).

    Tabelle 67: Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben

    Anwendungsfall
    Datenmenge
    in KB
    Lastanforderungen
    Anfragen
    [1/sec]
    Nachricht über KOM-LE-Clientmodul empfangen
            100
    302
         25.600
    15
    Nachricht über KOM-LE-Clientmodul Download
            100
    302
         25.600
    15
    Nachricht an KOM-LE-FD senden
            100
    160
         25.600
    8
    Nachricht von KOM-LE-FD empfangen
            100
    160
         25.600
    8
    Aufbau TLS-Kanal zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst
     
    820

    GS-A_5138-01 - Performance – KOM-LE-Fachdienst – Bearbeitungszeit unter Last

    Der Produkttyp KOM-LE-Fachdienst MUSS die Bearbeitungszeitvorgabe aus Tab_gemSpec_Perf_KOMLE_Clientmodul für den „Aufbau TLS-Kanal zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst“ unter der für diesen Anwendungsfall gemäß Tabelle Tab_gemSpec_Perf_KOMLE_Fachdienst anliegenden Spitzenlast für seine KOM-LE-Teilnehmer erfüllen. Der KOM-LE-Fachdienst muss diese Zeiten unter der Nebenbedingung erbringen, dass die anderen Produkttypen die Zeiten gemäß der Zerlegung der Bearbeitungszeiten in Tabelle Tab_gemSpec_Perf_KOMLE_Bearbeitungszeitbeiträge einhalten. Bei gecachten OCSP-Responses reduziert sich die Zeit um den dort angegebenen Betrag.
    [<=]

    Zur Erläuterung der Afo [GS-A_5138-01]:

    Der Anbieter muss die Anzahl seiner KOM-LE-Teilnehmer kennen und sein System mindestens so dimensionieren, dass die Lastvorgaben eingehalten werden.
    Beispielrechnung: Für 210.000 KOM-LE-Teilnhmer (siehe Tabelle "Tab_Mengengerüst: Annahmen für Modellierung") ergibt sich auf Basis von 10.000 Teilnehmern eines Anbieters eine Spitzenlast von 41 Anfragen pro Sekunde mit einer mittleren Bearbeitungszeit von 3,9 Sekunden für den Aufbau des TLS-Kanals zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst. (5% von 820 Anfragen pro Sekunde).

    GS-A_5143-01 - Performance – KOM-LE-Fachdienst – Nachricht senden

    Der KOM-LE-Fachdienst MUSS die vom KOM-LE-Clientmodul empfangenen E-Mails zeitnah an den KOM-LE-Fachdienst des E-Mail-Empfängers weiterleiten.

    Der KOM-LE-Fachdienst des E-Mail-Senders MUSS sicherstellen, dass der Zeitraum zwischen dem Zeitpunkt der quittierten Übergabe vom KOM-LE-Clientmodul an den KOM-LE-Fachdienst des E-Mail-Senders und dem Zeitpunkt der quittierten Übergabe an den KOM-LE-Fachdienst des E-Mail-Empfängers kleiner 10 Minuten ist.
    [<=]

    A_20127 - Performance - KOM-LE-Fachdienst – Spitzenlastvorgaben für den KAS

    Der Anbieter KOM-LE-Fachdienst MUSS den KAS so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß Tabelle "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS" erfüllt wird.

    Die Lastvorgaben sind für die vom Anbieter definierte maximale Größe der Zulässigen Anhänge zu erfüllen.

    Tabelle 68 Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS

    Schnittstellenoperationen
    Spitzenlast
    [1/sec]
    I_Attachment_Service::add_Attachment
    22
    I_Attachment_Service::read_Attachment
    30
    I_Attachment_Service::MaxMailSize
    22
    [<=]

    Zur Erläuterung der Afo [A_20127]:

    Der Anbieter muss die Anzahl seiner KOM-LE-Teilnehmer kennen und sein System mindestens so dimensionieren, dass die Lastvorgaben eingehalten werden.
    Beispielrechnung: Für 210.000 KOM-LE-Teilnhmer (siehe Tabelle "Tab_Mengengerüst: Annahmen für Modellierung") ergibt sich auf Basis von 10.000 Teilnehmern eines Anbieters eine Lastvorgabe von mindestens 1 Anfrage pro Sekunde für das Hochladen von Anhängen (I_Attachment_Service::add_Attachment) mit einer vom Anbieter definierten maximal zulässigen Größe von z. B. 250 MB. (5% von 22 Anfragen pro Sekunde).

    A_20130 - Performance - KOM-LE-Fachdienst - TLS Kanal KAS

    Der Anbieter KOM-LE-Fachdienst MUSS den KAS so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß "Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS"  für den Aufbau des TLS-Kanal zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst erfüllt wird.
    [<=]

    A_20132 - Performance - KOM-LE-Fachdienst - Spitzenlastvorgaben TU

    Der Anbieter KOM-LE MUSS in der TU-Umgebung 5% der in den folgenden Tabellen:

    definierten Vorgaben erfüllen.

    Ist der Marktanteil kleiner als 5% (10.500 KOM-LE-Teilnehmer) MUSS der Anbieter des KOM-LE-FAchdienstes nur den entsprechenden Prozentwert seines Marktanteils in der TU bereitstellen. Der Prozentwert MUSS mit angegeben werden. [<=]

    A_20133 - Performance - KOM-LE-Fachdienst - Anbindungsbandbreite

    Der Anbieter des KOM-LE-Fachdienstes MUSS die Bandbreite seiner Schnittstelle zum zentralen Netz der TI entsprechend der zu erwartenden Last auslegen. Die Auslastung der effektiven Bandbreite darf nicht dauerhaft über 90% der gewählten Anbindungsbandbreite liegen.
    [<=]

    A_20134 - Performance - KOM-LE-Fachdienst - Robustheit gegenüber Lastspitzen

    Der KOM-LE Fachdienst MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus den Tabellen:

    [<=]

    Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der KOM-LE-FAchdienst vorübergehend abweisen. Dabei müssen die definierten Spitzenlasten weiterhin innerhalb der Performancevorgaben verarbeitet werden. Vom System angenommene Anfragen müssen weiterhin innerhalb der Performancevorgaben verarbeitet werden. Der Anbieter hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.

    A_20135 - Performance - KOM-LE-Fachdienst - Skalierung

    Der Anbieter KOM-LE-Fachdienst MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird. [<=]

    Im Zuge des Zulassungsverfahrens hat der Anbieter KOM-LE-Fachdienst der gematik gegenüber nachvollziehbar darzustellen, welche technischen Skalierungsmaßnahmen anhand welcher messbarer Parameter er für den Produktivbetrieb plant durchzuführen. Die Skalierungsmaßnahmen können dabei unterschiedliche Ausprägungen und Dimensionen umfassen. Beispielsweise eine automatisierte Ressourcenzuteilung oder eine Anpassung oder Änderung unterschiedlicher technischer Komponenten, die zu einer Produktänderung im Sinne der [gemSpec_OM] führt. Die Darstellung muss Verifikationsbeschreibungen enthalten, mit denen der Erfolg der Maßnahmen ermittelt werden kann.

    A_20136 - Performance - Erfassung von Rohdaten - KOM-LE-Fachdienst

    Der KOM-LE-Fachdienst MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_KOM-LE – Operationen des Performance-Berichts_KOM-LE" erfassen und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
    [<=]

    A_20137 - Performance - Lieferung von Rohdaten - KOM-LE-Fachdienst

    Der KOM-LE-Fachdienst Anbieter MUSS in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678] liefern. Voreingestellt für das Zeitintervall ist täglich.
    [<=]

    GS-A_5139-01 - Performance – KOM-LE-Fachdienst – Verfügbarkeit

    Der Produkttyp KOM-LE-Fachdienst MUSS zur Hauptzeit eine Verfügbarkeit von 99,8% und zur Nebenzeit von 99% haben.

    Auch über Ausfälle hinweg MUSS der Produkttyp KOM-LE-Fachdienst gewährleisten, dass Nachrichten spätestens 10 Minuten nach dem erfolgreichen Versenden zum Abruf für den Empfänger bereitstehen.

    Wartungsfenster dürfen nur in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr, ausgenommen bundeseinheitliche Feiertage. Alle übrigen Stunden der Woche sind Nebenzeit.
    [<=]

    Außerdem gelten folgende Anforderungen für das Erfassen und Reporten von Performance-Kennzahlen: [GS-A_4146], [GS-A_4147], [GS-A_4148], [GS-A_4149].

    5.5 Produkttyp ePA-Aktensystem

    A_15208-01 - Performance - ePA-Aktensystem - Spitzenlastvorgaben

    Der Anbieter ePA-Aktensystem MUSS das Aktensystem so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast gemäß Tabelle "Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben-01" erfüllt wird. Die Lastvorgabe aus dieser Tabelle bezieht sich auf die Anzahl der gesetzlich Versicherten. [<=]

    Zur Erläuterung der Afo [A_15208-01]:

    Der Anbieter muss die Anzahl seiner Nutzer kennen und sein System mindestens so dimensionieren, dass die Lastvorgaben eingehalten werden.
    Beispielrechnung: Für 12,57 Mio. Nutzer (etwa 17,95% Marktanteil) muss für die Operation "I_Authentication_Insurant:login" eine Lastvorgabe von mindestens 11 Anfragen pro Sekunde eingehalten werden (17,95% von 60 Anfragen pro Sekunde).

    Tabelle 69: Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben-01

    Schnittstellenoperationen
    Lastvorgaben
    Bearbeitungszeitvorgaben
    Spitzenlast
    [1/sec]
    Mittelwert
    [msec]
    99%-Quantil
    [msec]
    I_Authentication_Insurant
     
     
    login
    60
    755
    960
    I_Authorization
     
     
    getAuthorizationKey
    100
    770
    980
    I_Authorization_Management
     
     
    putAuthorizationKey
    25
    520
    690
     
    checkRecordExists
    25
    100
    180
    I_Document_Management_Connect
     
     
    openContext
    100
    100
    180
    I_Document_Management
     
     
    CrossGatewayQuery
    100
    695
    895
     
    CrossGatewayRetrieve
    60
    430
    590
     
    CrossGatewayDocumentProvide
    40
    440
    600
     
    RemoveDocuments
    5
    680
    880
    I_Proxy_Directory_Query
     
     
    Search
    10
    1150
    1405

    A_15031-01 - Performance - ePA-Aktensystem - Bearbeitungszeit unter Last

    Das ePA-Aktensystem MUSS die Bearbeitungszeitvorgaben unter Last für die Schnittstellenoperationen aus Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben-01 erfüllen.

    Dabei gilt:


    [<=]

    Hinweis: Bei den in Tabelle "Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben" angegebenen Bearbeitungszeiten sind die Zeiten für die Übertragung der eingehenden und ausgehenden Nachrichten nicht enthalten.

    A_15236-01 - Performance - ePA-Aktensystem - Robustheit gegenüber Lastspitzen

    Das ePA-Aktensystem MUSS bei Lastspitzen oberhalb der definierten Spitzenlasten aus Tabelle "Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben-01" verfügbar bleiben. [<=]

    Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann das ePA-Aktensystem vorübergehend abweisen. Dabei müssen die definierten Spitzenlasten weiterhin innerhalb der Performancevorgaben verarbeitet werden. Vom System angenommene Anfragen müssen weiterhin innerhalb der Performancevorgaben verarbeitet werden. Der Anbieter ePA-Aktensystem hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.

    A_17998 - Performance - ePA-Aktensystem - Zugangsgateway des Versicherten - Lastvorgaben

    Der Anbieter ePA-Aktensystem MUSS die Komponente Zugangsgateway des Versicherten so dimensionieren, dass für seine Nutzer die erwartete Spitzenlast erfüllt wird. Der Marktanteil des Anbieters ist  prozentual auf die TI-Gesamtlast von 640 parallel eintreffenden Anfragen anzuwenden.  
    [<=]

    Zur Erläuterung der Afo [A_17998]:

    Der Anbieter muss für sein Marktanteil das System so dimensionieren, dass die Lastvorgaben am Zugangsgateway des Versicherten eingehalten werden.
    Beispielrechnung: Für ein Marktanteil von 20% und eine Lastvorgabe von 640 Anfragen pro Sekunde muss das Zugangsgateway des Versicherten mindestens 128 Anfragen pro Sekunde an die nachgelagerten Komponenten weiterleiten können.

    A_15213-01 - Performance - ePA-Aktensystem - Spitzenlastvorgaben TU

    Der Anbieter ePA-Aktensystem MUSS in der TU-Umgebung 5% der in Tabelle "Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben-01" geltenden Spitzenlastvorgaben unter Einhaltung der mittleren Bearbeitungszeiten erfüllen.

    Ist der Marktanteil kleiner als 5% MUSS der Anbieter ePA-Aktensystem nur den entsprechenden Prozentwert seines Marktanteils in der TU umsetzen. Der Prozentwert MUSS mit angegeben werden.
    [<=]

    Zur Erläuterung der Afo [A_15213-01]:
    Jeder Anbieter muss sein ePA-Aktensystem in der TU so dimensionieren, dass mindestens 5% der in Tabelle "Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben" erfüllt werden. 
    Beispielrechnung: Für die Operation "I_Authentication_Insurant:login" müssen mindestens 3 Anfragen pro Sekunde in der TU erfolgreich verarbeitet werden (5% von 60 Anfragen pro Sekunde). Die 5% - Regel gilt auch für die Dimensionierung der parallelen Anfragen über das Zugangsgateway des Versicherten (gemäß [A_17998]).

    A_15214 - Performance - ePA-Aktensystem - Speicherkapazität TU

    Der Anbieter ePA-Aktensystem MUSS eine Speicherkapazität von 300 GB in der TU bereit stellen.
    [<=]

    Aufbau sicherer Kanal zwischen der VAU und einem ePA-Client

    A_15698 - Performance - ePA-Aktensystem - Verbindungsaufbau

    Das ePA-Aktensystem MUSS beim Aufbau der sicheren Verbindung zwischen VAU und einem ePA-Client die Bearbeitungszeitvorgabe aus Tabelle Tab_gemSpec_Perf_ePA_Verbindungsaufbau bezüglich der von ihm verursachten Verarbeitungszeit erfüllen.

    Tabelle 70: Tabelle Tab_gemSpec_Perf_ePA_Verbindungsaufbau

    Bearbeitungszeitvorgaben
    Mittelwert
    [sec]
    95%-Quantil
    [sec]
    1,5
    1,7
    [<=]

    Der Anbieter ePA-Aktensystem erfasst Performance-Daten für die Bereitstellung des Verarbeitungskontextes der VAU durch Messung des Zeitraumes zwischen Empfang des ersten Client-Request der Session (valides VAUClientHello) bis zum vollständigen Senden der letzten Handshake-Nachricht (VAUServerFin) . Kann die Beantwortung nicht erfolgen und der Vorgang wird dadurch abgebrochen, dann muss dies als abgelehnter Aufruf gewertet werden. Die Zeit bis zum Abbruch wird nicht in der summierten Bearbeitungszeit erfasst.

    A_15212 - Performance - ePA-Aktensystem - Skalierung

    Der Anbieter ePA-Aktensystem MUSS nachvollziehbar darstellen, wie die Skalierung im Produktivbetrieb erreicht wird. [<=]

    Im Zuge des Zulassungsverfahrens hat der Anbieter ePA-Aktensystem der gematik gegenüber nachvollziehbar darzustellen, welche technischen Skalierungsmaßnahmen anhand welcher messbarer Parameter er für den Produktivbetrieb plant durchzuführen. Die Skalierungsmaßnahmen können dabei unterschiedliche Ausprägungen und Dimensionen umfassen. Beispielsweise eine automatisierte Ressourcenzuteilung oder eine Anpassung oder Änderung unterschiedlicher technischer Komponenten, die zu einer Produktänderung im Sinne der [gemSpec_OM] führt. Die Darstellung muss Verifikationsbeschreibungen enthalten, mit denen der Erfolg der Maßnahmen ermittelt werden kann.

    A_16177 - Performance - ePA-Aktensystem - Verfügbarkeit

    Der Anbieter ePA-Aktensystem MUSS zur Hauptzeit eine Verfügbarkeit von 99,9% und zur Nebenzeit von 99% für alle Operationen der technischen Schnittstellen aufweisen.

    Wartungsfenster MÜSSEN vollständig in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.

    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.

    Die Anschlüsse aller Standorte an das zentrale Netz MÜSSEN über die Anschlussoption "Hohe Verfügbarkeit" erfolgen.
    [<=]

    Die Verfügbarkeit der funktionalen Eigenschaften des ePA-Aktensystems wird mittels der Probes des Service Monitorings und die nicht funktionalen Eigenschaften durch Auswertung der Rohdaten ermittelt.

    A_18181 - Performance - Erfassung von Rohdaten - ePA-Aktensystem

    Das ePA-Aktensystem MUSS Performance-Rohdaten gemäß Tabelle "Tab_gemSpec_Perf_Berichtsformat_ePA" erfassen und die Rohdaten-Performance-Berichte in einem definierten, konfigurierbaren Zeitintervall automatisiert an den Endpunkt gemäß [A_17678] liefern.
    [<=]

    A_17293 - Performance - Lieferung von Rohdaten - ePA-Aktensystem

    Der Anbieter ePA-Aktensystem MUSS in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte (Performance Protokoll und Datei zur Selbstauskunft) automatisiert an den Endpunkt gemäß [A_17678] liefern. Voreingestellt für das Zeitintervall ist täglich. [<=]

    A_15743 - Performance - ePA-Aktensystem - Bestandsdaten

    Der Anbieter ePA-Aktensystem MUSS im Performance-Report zu einem Stichtag des betreffenden Erfassungszeitraums folgende Performance-Kenngrößen über das ePA-Aktensystem berichten:

    Der Anbieter ePA-Aktensystem MUSS die Bestandsdaten an den Endpunkt gemäß [gemSpec_SST_LD_BD] liefern.

    [<=]

    A_20204-01 - Performance - ePA-Aktensystem - Lieferweg und Format für Bestandsdaten

    Das ePA-Aktensystem MUSS die Informationen aus A_15743 jeweils monatlich zum 01. des Monats in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß gemSpec_SST_LD_BD liefern:
    {
                    „Abfragezeitpunkt“: <Zeitstempel der Abfrage als String im ISO 8601 Format>,
                    „CI_ID“: <CI ID des abgefragten Aktensystems gemäß TI-ITSM als String>,
                    „ePA_AS_Anzahl_Konten“: <Anzahl der zum Abfragezeitpunkt vorhandenen Konten als Integer>,
                    „ePA_AS_Anzahl_Dokumente“: <Anzahl der zum Abfragezeitpunkt vorhandenen Dokumente (über alle Konten) als Integer>,
                    „ePA_AS_Datenvolumen“: <Datenvolumen des kompletten Aktensystems zum Abfragezeitpunkt in kByte als Integer>
    }

    [<=]

    "Da bei dieser Lieferung keine Datei übermittelt wird, sondern der Text direkt im Body, ist für diese Lieferung die Angabe des filenames im HTTP Header gemäß [A_17733-01] (Tabelle: Tab_I_OpsData_Update_002 Operation I_OpsData_Update::fileUpload) in der gemSpec_SST_LD_BD NICHT notwendig."

    5.6 Produkttyp APOVZD

    5.6.1 Verfügbarkeit

    Die Anforderungen an die Verfügbarkeit des Apothekenverzeichnisses richten sich nach der geforderten Verfügbarkeit der Schnittstellen des neuen Produkttyps, d.h. die Schnittstellen zum Abruf und Pflege der Apothekeninformationen müssen die gleiche Verfügbarkeit aufweisen.

    A_21270 - Performance - Apothekenverzeichnis - Verfügbarkeit

    Der Produkttyp Apothekenverzeichnis MUSS zur Hauptzeit eine Verfügbarkeit von 99,8 % und zur Nebenzeit von 99 % für alle Operationen der technischen Schnittstellen aufweisen.
    Wartungsfenster MÜSSEN vollständig in der Nebenzeit liegen. Genehmigte Wartungsfenster werden nicht als Ausfallzeit gewertet.
    Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr sowie Samstag und Sonntag von 6 bis 20 Uhr. Alle übrigen Stunden der Woche sind Nebenzeit. Bundeseinheitliche Feiertage werden wie Sonntage behandelt, alle übrigen Feiertage wie Werktage.
    [<=]

    5.6.2 Last

    Zur Abschätzung der Leistung der benötigten Hardware wird ein Anfrageaufkommen durch Clients (E-Rezept-FdV) geschätzt.

    Tabelle 71: Tab_eRp_APOVZD_Anfrageaufkommen 

    Anzahl potentieller Nutzer ~80.000.000
    Annahme regelmäßige Nutzer E-Rezept-FdV (mittelfristig): 10 % der potentiellen Nutzer 8.000.000
    Anzahl Rezepte pro Quartal: (1,7 - Dauermedikation, Chroniker) ~2,
    ergibt eine Anzahl Apothekenbesuche pro Quartal.
    1
    Unabhängig vom Cache der Apothekeninformationen wird angenommen, dass ein Client den Cache innerhalb eines Quartals aktualisiert, ergibt Aufrufe am Apothekenverzeichnis pro Quartal. 16.000.000
    Anzahl Wochentage pro Quartal (Mo. – Fr.), abgeleitet aus durchschnittlichen Praxisöffnungszeiten). 65
    Ergibt Anzahl Aufrufe am Apothekenverzeichnis pro Tag. ~246.000
    Anteil Spitzenstunde werktags: 1/5, ergibt Anzahl Aufrufe am Apothekenverzeichnis pro Spitzenstunde. ~50.000
    Ergibt Anzahl Aufrufe am Apothekenverzeichnis pro Minute der Spitzenstunde. ~833
    ergibt Anzahl Aufrufe am Apothekenverzeichnis pro Sekunde der Spitzenstunde ~14

    Die Abschätzung ergibt ca. 14 parallele Aufrufe pro Sekunde.

    5.6.3 Antwortzeiten

    Die Informationen des Apothekenverzeichnisses stellen keine Voraussetzung für die Use Cases des E-Rezepts dar. Zudem wird davon ausgegangen, dass Clients Apothekeninformationen aus vorangegangenen Abfragen cachen. Eine Abschätzung der erwarteten Ergebnismenge pro Anfrage durch Clients ist ebenso schwer umzusetzen, da Suchkriterien von Versicherten stark variieren können und ebenso eine "Standardumkreissuche" an verschiedenen Orten in Deutschland eine verschiedene Anzahl Apotheken zurückgeben würde.

    Die gematik beobachtet das Antwortzeitverhalten des Apothekenverzeichnisses im Rahmen des Servicemonitorings.

    A_21189 - Apothekenverzeichnis - Bearbeitungszeit unter Last

    Der Produkttyp Apothekenverzeichnis MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_eRp_APOVZD: Last- und Bearbeitungszeitvorgaben" bei anliegender Spitzenlast erfüllen.

    Tabelle 72: Tab_eRp_APOVZD: Last- und Bearbeitungszeitvorgaben

    UseCase Bezug Operation Spitzenlast
    [1/s]
    Mittelwert
    [ms]
    99 %-Quantil
    [ms]
    APO.UC_1_1 GET /Location
    GET /HealthcareService
    14 1000 1300
    [<=]

    5.6.4 Bereitstellung Betriebsdaten

    Die Rohdatenlieferung eines Produkttyps erfasst das Performanceverhalten von Diensten der TI.
    Diese Rohdaten beinhalten folgende Informationen:

    Aus den Rohdaten lassen sich die Performance-Kenngrößen und Service Level sowie die Abbruchquote (Anteil der nicht erfolgreich verarbeiteten Aufrufe gemessen an der Anzahl der Aufrufe) für den Produkttyp ermitteln.
    Die Rohdaten werden vom Produkttyp erfasst und durch den Anbieter an den definierten Endpunkt gemeldet.
    Ausfälle eines Produkttyps werden über die Rohdaten nicht direkt gemeldet, dies erfolgt über das parallel durchgeführte Probing. Produkttypen erfassen Performance-Kenngrößen, protokollieren sie in einem Performance-Protokoll und stellen sie in dem hier festgelegten Performance-Berichtsformat bereit.

    A_21271 - Apothekenverzeichnis - Erkennung Clientsystem User-Agent

    Das Apothekenverzeichnis MUSS das vom aufrufenden Nutzer verwendete Clientsystem anhand des im HTTP-Request enthaltenen Header-Feld "User-Agent" gemäß [RFC7231] erkennen und in den Einträgen zur Performance-Rohdatenerfassung als $useragent gemäß [A_21272] protokollieren.
    Das Apothekenverzeichnis MUSS bei fehlendem User-Agent-Header den Request mit dem HTTP-Status-Code 403 beantworten, damit in der Betriebsüberwachung des E-Rezept-Fachdienstes die Nutzung unzulässiger Frontends erkannt werden kann.
    Dabei MUSS die Lieferung für $message im JSON-Format erfolgen, das heißt für $message der Wert $message = {"UA": "$useragent ", " Status ": $status}. Für $status ist der http-Code gemäß [A_21272] zu verwenden und es sind die folgenden Datenformate zu benutzen:
    Typ UA: string
    Typ Status: number (int)

    [<=]

    A_21272 - Apothekenverzeichnis - Rohdaten-Performance-Berichte - Format der Einträge des Performance Berichts Apothekenverzeichnis

    Das Apothekenverzeichnis MUSS beim Übermitteln der Performance-Messwerte in einem Rohdaten-Performance-Bericht sämtliche Zeilen (Einträge) der Berichte in der folgenden Weise formatieren:

    INFO:start[$timestamp] time[$duration_in_ms] tag[$operation] size[$size_in_kb] message[$message],

    mit
    $timestamp ein Unixzeit-Zeitstempel in Millisekunden,
    $duration_in_ms die gemessene Bearbeitungszeit einer Operation in Millisekunden,
    $operation ist die ausgeführte Operation $APO-operation des Produkttyps gemäß Tabelle Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis
    $size_in_kb ist die gemessene, übertragene Datenmenge einer Operation in Kilobyte.
    $message (gemäß [A_21271])

    Tabelle 73 : Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis

    $APO-operation Produkttyp Operation
    APO.UC_1_1 Apothekenverzeichnis GET /Location
    GET /HealthcareService
    APO.UC_2_1 Apothekenverzeichnis POST/PUT/PATCH/DELETE /Location
    POST/PUT/PATCH/DELETE /HealthcareService
    [<=]

    A_21273 - Apothekenverzeichnis - Messpunkte für die Erfassung von Rohdaten am E-Rezept-Fachdienst

    Das Apothekenverzeichnis MUSS die in der Tabelle Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis aufgeführten Operationen/Use Cases messen. Die Messung beginnt mit der Annahme der Aufrufnachricht an der annehmenden Schnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht an die annehmende Schnittstelle des Empfängers. Registriert wird der Zeitpunkt und die HTTP-Statuscodes aus dem Header und wird gemäß A_21272 formatiert sowie für $operation der Wert $operation = $APO-operation gemäß der Tabelle Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis gesetzt. [<=]

    A_21276 - Apothekenverzeichnis - Erfassung von Rohdaten bei fehlerhaften Operationen

    Das Apothekenverzeichnis MUSS jede Operation, welche nicht fehlerfrei durchlaufen wurde, in den Rohdaten gemäß A_21272 formatieren. Dabei MUSS für $operation der Wert $operation = $APO-operation + ".failed" gesetzt werden, wobei +".failed" nur anzuhängen ist, insofern einer der HTTP-Statuscodes gemäß Tabelle Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis_Failure vom Apothekenverzeichnis zurückgeliefert wird. 

    Tabelle 74: Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis_Failure 

    HTTP-Statuscode Beschreibung
    408 Das Apothekenverzeichnis ist überlastet und kann die Anfrage innerhalb der Wartezeit des Clients nicht beantworten.
    5xx Alle HTTP-Statuscodes, die auf einen internen Systemfehler hinweisen.

    Zusätzlich MUSS die Lieferung für $message im JSON-Format erfolgen, das heißt für $message der Wert $message = {"UA": "$useragent ", " Status ": $status}. Für $status ist der http-Code gemäß [A_21272] zu verwenden und es sind die folgenden Datenformate zu benutzen:
    Typ UA: string
    Typ Status: number (int)

    [<=]

    A_21331 - Apothekenverzeichnis - Lieferung von Rohdaten

    Der Anbieter Apothekenverzeichnis MUSS das Produkt Apothekenverzeichnis so konfigurieren, dass dieses in einem definierten, konfigurierbaren Zeitintervall Rohdaten-Performance-Berichte und die Datei zur Selbstauskunft automatisiert an die Betriebsdatenerfassung gemäß [A_17678] liefert. Voreingestellt für das Zeitintervall sind 5 Minuten.
    [<=]

    6 Anhang A – Verzeichnisse

    6.1 Glossar

    Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.

    6.2 Abbildungsverzeichnis

  • Abbildung 1: Beispiel für Zerlegung einer Funktion und die Modell-Bearbeitungszeitgrößen
  • Abbildung 2: Beispiel für gemessene Aufrufe, die zu Aufrufzeitpunkten erfolgen
  • Abbildung 3: Beispiel einer über den Zeitraum T gemittelten Aufrufrate
  • Abbildung 4: Entwicklung der Spitzenlast (oder mehreren fallabhängigen Spitzenlasten) aus einer Durchschnittslast pro Jahr.
  • Abbildung 5: Quadranten der Kombination aus Bearbeitungszeit- und Lastanforderungen
  • Abbildung 6: Messpunkte zur Konnektor Performance-Messung
  • Abbildung 7: Messaufbau zum IPSec-Durchsatzmessung
  • Abbildung 8: Messpunkte zur Kartenterminal Performance-Messung
  • Abbildung 9: Netzwerktopologie – Punkte mit Lastvorgaben (orange)
  • 6.3 Tabellenverzeichnis

  • Tabelle 1 : Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02
  • Tabelle 2: Tab_gemSpec_Perf_Standard-Statuscodes 
  • Tabelle 3: Tab_Bearbeitungszeitvorgaben Tokenbasierte Authentisierung je Anwendungsfall
  • Tabelle 4: Tab_gemSpec_Perf_IDP-Dienst: Bearbeitungszeitvorgaben
  • Tabelle 5: Tab_gemSpec_Perf_sek_IDP: Bearbeitungszeitvorgaben
  • Tabelle 6: Tab_gemSpec_Perf_sektoraler_IDP: Bearbeitungszeitvorgaben
  • Tabelle 7: Tab_gemSpec_Perf_Berichtsformat_IDP
  • Tabelle 8: Tab_gemSpec_Perf_Fehlercodes_IdP-Dienst
  • Tabelle 9: Tab_gemSpec_Perf_Fehlercodes_sektoraler_IDP
  • Tabelle 10: Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP
  • Tabelle 11: Tab_Lastmodell E-Rezept aus der LE-U für Praxen, Apotheken und Versicherte
  • Tabelle 12: Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall
  • Tabelle 13 Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben
  • Tabelle 14 Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst
  • Tabelle 15: Tab_gemSpec_Perf_Berichtsformat_TSP-X.509
  • Tabelle 16: Tab_gemSpec_Perf_FedMaster: Bearbeitungszeitvorgaben
  • Tabelle 17: Tab_Mengengerüst: Versicherte und Leistungserbringer
  • Tabelle 18: Tab_Mengengerüst: Lokationen
  • Tabelle 19: Tab_Mengengerüst: Krankenhäuser (Quelle: [DKG2010])
  • Tabelle 20: Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen
  • Tabelle 21: Tab_Mengengerüst: Annahmen für Modellierung
  • Tabelle 22: Tab_VSDM Anwendungsfälle
  • Tabelle 23: Tab_Lastmodell: Nutzung bestehender Anwendungen und Netze
  • Tabelle 24: Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs
  • Tabelle 25: Tab_Lastmodell der Basisdienste QES für Leistungserbringer (LE) Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs
  • Tabelle 26: Tab_Lastmodell der Basisdienste QES in Krankenhäuser mit stationären Fällen
  • Tabelle 27: Tab_Lastmodell: Krankenhäuser (Quelle: [DKG2010])
  • Tabelle 28: Tab_Lastmodell KOM-LE-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs
  • Tabelle 29: Tab_Lastmodell: KOM-LE in Krankenhäusern
  • Tabelle 30: Tab_Lastmodell: KOM-LE-Anwendungsfälle für große Nachrichten
  • Tabelle 31: Tab_Lastmodell NFDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs
  • Tabelle 32: Tab_Lastmodell eMP/AMTS-Anwendungsfälle in Praxen und Apotheken
  • Tabelle 33: Tab_Lastmodell ePA aus der LE-U für Praxen, Apotheken und Krankenhäuser
  • Tabelle 34: Tab_ePA-Anwendungsfälle je LE-U
  • Tabelle 35: Tab_Lastmodell ePA aus der Versicherten-Umgebung
  • Tabelle 36: Tab_Mengenrahmen „Update Konnektor und Kartenterminals“
  • Tabelle 37: Tab_Bearbeitungszeitvorgaben KOM-LE je Anwendungsfall
  • Tabelle 38: Tab_Bearbeitungszeitvorgaben NFDM je Anwendungsfall
  • Tabelle 39: Tab_Bearbeitungszeitvorgaben eMP/AMTS je Anwendungsfall
  • Tabelle 40: Tab_ePA Bearbeitungszeitvorgaben je Anwendungsfall
  • Tabelle 41: Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus
  • Tabelle 42: Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus im Kontext von E-Rezept
  • Tabelle 43: Tab_Caching-Dauer
  • Tabelle 44: Tab_gemSpec_Perf_Konnektor – Last- und Bearbeitungszeitvorgaben
  • Tabelle 45: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B
  • Tabelle 46: Tab_gemSpec_Perf_Konnektor_Parallele_Verarbeitung_SMC-B_AMTS
  • Tabelle 47: Tab_gemSpec_Perf_Konnektor_Stapelsignatur – Parallelverarbeitung gemäß Lastmodell
  • Tabelle 48: Tab_gemSpec_Perf_Konnektor_Stapelsignatur_Perspektivisch – Parallelverarbeitung perspektivisch
  • Tabelle 49: Tab_Fachmodul_ePA - Last- und Bearbeitungszeitvorgaben
  • Tabelle 50 : Tab_gemSpec_Perf_ePA_Parallele_Verarbeitung
  • Tabelle 51: Tab_gemSpec_Perf_Kartenterminal_Bearbeitungszeitvorgabe
  • Tabelle 52: Tab_gemSpec_Perf_Verzeichnisdienst: Last- u. Bearbeitungszeitvorgaben
  • Tabelle 53: Tab_gemSpec_Perf_Konfigurationsdienst: Last- u. Bearbeitungszeitvorgaben
  • Tabelle 54: Tab_gemSpec_Perf_TSL-Dienst: Lastvorgaben
  • Tabelle 55: Tab_gemSpec_Perf_OCSP_Responder – Last- und Bearbeitungszeitvorgaben
  • Tabelle 56: Tab_gemSpec_Perf_CRL-Dienst: Lastvorgaben
  • Tabelle 57: Tab_gemSpec_Perf_TSP_Provisioning_Revocation: Bearbeitungszeitvorgaben
  • Tabelle 58: Tab_gemSpec_Perf_Störungsampel – Lastvorgaben
  • Tabelle 59: Tab_gemSpec_Perf_Namensdienst: Last- u. Bearbeitungszeitvorgaben
  • Tabelle 60: Tab_gemSpec_Perf_Netzlast_1 Spitzenlasten am VPN-Zugangsdienst (Punkt 1)
  • Tabelle 61: Tab_gemSpec_Perf_Signaturdienst: Last- u. Bearbeitungszeitvorgaben
  • Tabelle 62: Tab_gemSpec_Perf_Schlüsselgenerierungsdienst: Last- u. Bearbeitungszeitvorgaben
  • Tabelle 63 Tab_gemSpec_Perf_Intermediaer: Bearbeitungszeitvorgaben
  • Tabelle 64: Tab_gemSpec_Perf_VSDM_Fachdienste: Last- und Bearbeitungszeitvorgaben
  • Tabelle 65: Tab_gemSpec_Perf_KOMLE_Clientmodul: Last- und Bearbeitungszeitvorgaben
  • Tabelle 66: Tab_gemSpec_Perf_KOMLE_Bearbeitungszeitbeiträge: Zerlegung Bearbeitungszeiten
  • Tabelle 67: Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben
  • Tabelle 68 Tab_gemSpec_Perf_KOMLE_Fachdienst: Lastvorgaben des KAS
  • Tabelle 69: Tab_ePA_Aktensystem - Last- und Bearbeitungszeitvorgaben-01
  • Tabelle 70: Tabelle Tab_gemSpec_Perf_ePA_Verbindungsaufbau
  • Tabelle 71: Tab_eRp_APOVZD_Anfrageaufkommen 
  • Tabelle 72: Tab_eRp_APOVZD: Last- und Bearbeitungszeitvorgaben
  • Tabelle 73 : Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis
  • Tabelle 74: Tab_eRp_APOVZD_Berichtsformat_Apothekenverzeichnis_Failure 
  • Tabelle 75: Tab_gemSpec_Perf_Konnektorbearbeitungszeiten_pro_Komponente
  • Tabelle 76: Tab_gemSpec_Perf_Berichtsformat_VSDM – Operationen des Performance-Berichts VSDM
  • Tabelle 77: Tab_gemSpec_Perf_Berichtsformat_ePA – Operationen des Performance-Berichts ePA
  • Tabelle 78: Tab_gemSpec_Perf_Berichtsformat_SigD – Operationen des Performance-Berichts SigD
  • Tabelle 79: Tab_gemSpec_Perf_Berichtsformat_SGD – Operationen des Performance-Berichts SGD
  • Tabelle 80: Tab_gemSpec_Perf_Berichtsformat_KOM-LE – Operationen des Performance-Berichts_KOM-LE
  • Tabelle 81: Tab_gemSpec_Perf_Berichtsformat_Intermediär VSDM – Operationen des Performance-Berichts Intermediär VSDM
  • Tabelle 82: Tab_gemSpec_Perf_Berichtsformat_TI-Messenger-Fachdienst <3
  • Tabelle 83: Tab_gemSpec_Perf_Einbox_Konnektor_Last_8_Anwendungen
  • Tabelle 84: Tab_gemSpec_Perf_Einbox_Konnektor_Lastsituationen
  • Tabelle 85: Tab_gemSpec_Perf_HighSpeed_Konnektor_Last_8_Anwendungen
  • Tabelle 86: Tab_gemSpec_Perf_HighSpeed_Konnektor_Lastsituationen
  • Tabelle 87: Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben
  • Tabelle 88: Tab_gemSpec_Perf_Einbox_QES-Konnektor_Lastsituationen
  • Tabelle 89: Tab_gemSpec_Perf_HighSpeed_QES-Konnektor_Lastsituationen
  • 6.4 Referenzierte Dokumente

    6.4.1 Dokumente der gematik

    Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

    [Quelle]
    Herausgeber: Titel
    [gemGlossar]
    gematik: Glossar
    [gemKPT_Arch_TIP]
    gematik: Architekturkonzept der TI-Plattform
    [gemKPT_Perf_VSDM]
    gematik: Systemspezifisches Konzept Performanceuntersuchung (VSDM)
    [gemRL_Betr_TI]
    gematik: Übergreifende Richtlinien zum Betrieb der TI
    [gemKPT_Betr] gematik: Betriebskonzept Online-Produktivbetrieb
    [gemSpec_FM_VSDM]
    gematik: Spezifikation Fachmodul VSDM
    [gemSpec_Intermediär_VSDM]
    gematik: Spezifikation Intermediär VSDM
    [gemSpec_Net]
    gematik: Spezifikation Netzwerk
    [gemSpec_COS]
    gematik: Spezifikation des Card Operating System (COS) – Elektrische Schnittstelle
    [gemSpec_eGK_P1]
    gematik: Die Spezifikation elektronische Gesundheitskarte; Teil 1 – Spezifikation der elektrischen Schnittstelle
    [gemKPT_Test]
    gematik: Testkonzept
    [gemSysL_KOM-LE]
    gematik: Systemspezifisches Konzept – Kommunikation Leistungserbringer (KOM-LE)
    [gemSysL_NFDM] gematik: Systemspezifisches Konzept Notfalldaten-Management (NFDM)
    [gemSysL_AMTS_A]
    gematik: Systemspezifisches Konzept
    eMP/AMTS-Datenmanagement (Stufe A)
    [gemSysL_ePA]
    gematik: Systemspezifisches Konzept elektronische Patientenakte (ePA)
    [gemSpec_OM]
    gematik: Übergreifende Spezifikation Operations und Maintenance
    [gemSpec_Aktensystem]
    gematik: Spezifikation ePA-Aktensystem
    [gemSpec_SST_LD_DB]
    gematik: Spezifikation Schnittstelle Logdaten- und Betriebsdatenerfassung
    [gemSysL_eRp] gematik: Systemspezifisches Konzept E-Rezept

    6.4.2 Weitere Dokumente

    [Quelle]
    Herausgeber (Erscheinungsdatum): Titel
    [DKG2010]
    Deutsche Krankenhaus Gesellschaft (DKG):
    Kenngrößen für den Konnektor im Krankenhaus
    [GBE_Bund]
    Gesundheitsberichterstattung des Bundes
    [KBV2010]
    Kassenärztliche Bundesvereinigung, Grunddaten 2011, http://www.kbv.de/publikationen/125.html
    [KBVPraxen2010]
    Kassenärztliche Bundesvereinigung (16.09.2011): Praxen / MVZ
    http://www.kbv.de/print/24853.html
    [KZBV2010]
    Kassenzahnärztliche Bundesvereinigung (Jahrbuch 2011)
    http://www.kzbv.de/statistische-basisdaten.5.de.html
    [UnabhZufall]
    Herleitung der Summenregeln für Mittelwerte und Varianzen aus dem Additionssatz für Verteilungen
    http://www.vwi.tu-dresden.de/~treiber/statistik2/statistik_download/exkurse15.pdf
    [ABDA2016]
    DIE APOTHEKE – ZAHLEN, DATEN, FAKTEN 2016,
    ABDA – Bundesvereinigung Deutscher Apothekerverbände
    https://www.abda.de/uploads/tx_news/ABDA_ZDF_2016_Brosch.pdf
    [ABDA2018]
    DIE APOTHEKE – ZAHLEN, DATEN, FAKTEN 2018,
    ABDA – Bundesvereinigung Deutscher Apothekerverbände
    https://www.abda.de/fileadmin/assets/ZDF/ZDF_2018/ABDA_ZDF_2018_Brosch.pdf 
    [GKVKassen2019]
    GKV-Spitzenverband (21.01.2019): Krankenkassenliste
    https://www.gkv-spitzenverband.de/krankenkassenliste.pdf 
    [Perf4J]
    Performance Monitoring and Statistics for Java Code
    https://github.com/perf4j 

    7 Anhang B – Modelldetails

    7.1 Verteilung der Konnektorbearbeitungszeiten auf Komponenten

    Die Bearbeitungszeitvorgaben in "Tab_gemSpec_Perf_Konnektor – Last- und Bearbeitungszeitvorgaben" an den Konnektor beinhalten die interne Bearbeitungszeit des Konnektors, des Kartenterminals mit Karte, des Leistungserbringer-LANs und des OCSP-Responders. Wie sich die vom Konnektor gesamt zu verantwortende Bearbeitungszeit auf diese einzelnen Komponenten verteilt, gibt "Tab_gemSpec_Perf_Konnektorbearbeitungszeiten_pro_Komponente" an.


    Tabelle 75: Tab_gemSpec_Perf_Konnektorbearbeitungszeiten_pro_Komponente

    Schnittstellenoperationen
    Konnektor Gesamt
    [msec]
    Konnektor intern
    mit LE-LAN
    [msec]
    Kartenterm. + Karte
    [msec]
    OCSP + Zugangsnetz+ Zentr.Netz [msec]
    Lesen VSD mit Onlineprüfung
    mit Aktualisierung
    6130
    1250
    3780
    1100
    Lesen VSD mit Onlineprüfung
    ohne Aktualisierung
    3940
    790
    3150
    0
    Lesen VSD ohne Onlineprüfung
    3820
    610
    3210
    0
    Automatische Onlineprüfung
    mit Aktualisierung der VSD
    5720
    1030
    3590
    1100
    Automatische Onlineprüfung
    ohne Aktualisierung der VSD
    3130
    460
    2670
    0
    NFD von eGK lesen
    7260
    1070
    4080
    2110
    NFD auf eGK schreiben
    5780
    850
    4930
    0
    NFD von eGK löschen
    4800
    810
    3990
    0
    DPE von eGK lesen
    4300
    935
    3365
    0
    DPE auf eGK schreiben
    4590
    975
    3615
    0
    DPE von eGK löschen
    4260
    810
    3450
    0
    I_AMTS_Service::ReadMP
    5268
    1010
    4258
    0
    I_AMTS_Service::WriteMP
    (mit C2C)
    6625
    1120
    5505
    0
    I_AMTS_Service::WriteMP
    (ohne C2C)
    4020
    1020
    3000
    0
    I_Sign_Operations::sign_Document
    (10 kB)
    1010
    300
    710
    0
    I_Sign_Operations::sign_Document
    (100 kB)
    1030
    320
    710
    0
    I_Sign_Operations::sign_Document
    (1 MB)
    (XAdES, XML_1MB, enveloped)
    (CAdES, TIFF_1MB, detached)
    (PAdES, PDFA_2b_1MB_Komplex)  
    1440
    730
    710
    0
    I_Sign_Operations::sign_Document
    (XAdES, XML_25MB, enveloped)
    10500
    9790
    710

    I_Sign_Operations::sign_Document
    (CAdES, TIFF_25MB, detached)
    7300
    6590
    710

    I_Sign_Operations::sign_Document
    (PAdES, PDFA_2b_25MB_Bilder_
    und_Text)
    7300
    6590
    710

    I_Sign_Operations::verify_Document
    (10 kB)
    1570

    470

    0
    1100
    I_Sign_Operations::verify_Document
    (100 kB)

    1600

    500

    0
    1100
    I_Sign_Operations::verify_Document
    (1 MB)
    (XAdES, XML_1MB, enveloped)
    (CAdES, TIFF_1MB, detached)
    (PAdES, PDFA_2b_1MB_Komplex)
    1930
    830
    0
    1100
    I_Sign_Operations::verify_Document
    (XAdES, XML_25MB, enveloped, IncludeRevocationInfo=false)
    9000
    7900
    0
    1100
    I_Sign_Operations::verify_Document  
    (CAdES, TIFF_25MB,
    IncludeRevocationInfo=false)
    9000
    7900
    0
    1100
    I_Sign_Operations::verify_Document  
    (PAdES, PDFA_2b_25MB, IncludeRevocationInfo=false)
    10600
    9500
    0
    1100
    I_SAK_Operations::sign_Document_
    QES (10KB)
    3540
    520
    910
    2110
    I_SAK_Operations::sign_Document_
    QES (100KB, Stapelgröße 1, SE#1)

    3790

    770

    910

    2110
    I_SAK_Operations::sign_Document_
    QES (100KB, Stapelgröße 2, SE#2)
    8870
    1430
    5330
    2110
    I_SAK_Operations::sign_Document_
    QES (1MB)

    4070

    1050

    910

    2110
    I_SAK_Operations::sign_Document_
    QES (25MB)




    I_SAK_Operations::sign_Document_
    QES
    (XAdES, XML_25MB, enveloped)
    12810
    9790
    910
    2110
    I_SAK_Operations::sign_Document_
    QES
    (CAdES, TIFF_25MB)
    9610
    6590
    910
    2110
    I_SAK_Operations::sign_Document_
    QES
    (PAdES, PDFA_2b_25MB)
    9610
    6590
    910
    2110
    I_SAK_Operations::verify_Document_
    QES (10KB)
    2580
    470
    0
    2110
    I_SAK_Operations::verify_Document_
    QES (100KB)
    0
    2610

    500
    0
    2110
    I_SAK_Operations::verify_Document_
    QES (1 MB)
    2940
    830
    0
    2110
    I_SAK_Operations::verify_Document_
    QES
    (XAdES, XML_25MB, enveloped, IncludeRevocationInfo=false)
    10010
    7900
    0
    2110
    I_SAK_Operations::verify_Document_
    QES  (CAdES, TIFF_25MB, IncludeRevocationInfo=false)
    10010
    7900
    0
    2110
    I_SAK_Operations::verify_Document_
    QES  (PAdES, PDFA_2b_25MB, IncludeRevocationInfo=false)
    11610
    9500
    0
    2110
    I_KV_Card_Unlocking::authorize_Card (no Cache)
    2020
    100
    1920
    0
    I_KV_Card_Unlocking::authorize_Card (Cache)
    1830
    100
    1730
    0
    I_Crypt_Operations::encrypt_Document (10 kB)
    1860
    760
    0
    1100
    I_Crypt_Operations::encrypt_Document (100 kB)
    1880
    780
    0
    1100
    I_Crypt_Operations::encrypt_Document (1 MB)
    2200
    1100
    0
    1100
    I_Crypt_Operations::encrypt_Document
    (XMLEnc, XML_25MB, ein Empfänger)
    10600
    9500
    0
    1100
    I_Crypt_Operations::encrypt_Document
    (CMS, TIFF_25MB, ein Empfänger)
    7800
    6700
    0
    1100
    I_Crypt_Operations::decrypt_Document (10 kB)
    490
    150
    340
    0
    I_Crypt_Operations::decrypt_Document (100 kB)
    510
    170
    340
    0
    I_Crypt_Operations::decrypt_Document (1 MB)(XMLEnc, XML_1MB)(CMS, TIFF_1MB)
    820
    480
    340
    0
    I_Crypt_Operations::decrypt_Document
    (XMLEnc, XML_25MB)
    8900
    8560
    340

    I_Crypt_Operations::decrypt_Document
    (CMS, TIFF_25MB)
    8900
    8560
    340

    I_Cert_Verification::verify_Certificate
    1150
    50
     0
    1100
    I_Directory_Query::search_Directory
    2220
    2000
     0
    220

    8 Anhang C – Performance-Berichtsformate

    Im Folgenden werden die zur Erstellung des Rohdaten-Performance-Berichts zu verwendenden Operationen je Produkttyp aufgelistet.

    Tabelle 76: Tab_gemSpec_Perf_Berichtsformat_VSDM – Operationen des Performance-Berichts VSDM

    $operation
    Produkttyp
    Operation
    Beschreibung
    UFS.GetUpdateFlags
    UFS
    GetUpdateFlags
    Bei Aufruf der Operation GetUpdateFlags beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum Intermediär VSDM.
    VSDD.PerformUpdates
    VSDD
    PerformUpdates
    Bei Aufruf der Operation PerformUpdates beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum Intermediär VSDM.
    VSDD.GetNextCommand-
    Package
    VSDD
    GetNextCommand-Package
    Bei Aufruf der Operation GetNextCommandPackage beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum Intermediär VSDM.
    CMS.PerformUpdates
    CMS
    PerformUpdates
    Bei Aufruf der Operation PerformUpdates beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum Intermediär VSDM.
    CMS.GetNextCommand-
    Package
    CMS
    GetNextCommand-Package
    Bei Aufruf der Operation GetNextCommandPackage beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum Intermediär VSDM.

    Tabelle 77: Tab_gemSpec_Perf_Berichtsformat_ePA – Operationen des Performance-Berichts ePA

    $operation
    Produkttyp
    Operation
    Beschreibung
    VAU_Context
    ePA-
    Aktensystem
    Bereitstellung des Verarbeitungskontextes der VAU
    Bei Empfang der VAUClientHello-Nachricht beginnt die Messung und endet mit dem vollständigen Versenden der VAUServerFin-Nachricht (gemäß [A_15698]).
    I_Authentication_Insurant::
    login
    ePA-Aktensystem
    login
    Bei Aufruf der Operation beginnt die Messung mit Annahme der Aufrufnachricht an der Außenschnittstelle des Produkttyps und endet mit dem vollständigen Versenden der Antwortnachricht.
    I_Authentication_Insurant::
    renew
    ePA-Aktensystem
    renew
    I_Authentication_Insurant::
    logout
    ePA-Aktensystem
    logout
    I_Authorization:: getAuthorizationKey
    ePA-Aktensystem
    getAuthorizationKey
    I_Authorization_Insurant::
    getAuthorizationKey
    ePA-Aktensystem
    getAuthorizationKey

    Tabelle 78: Tab_gemSpec_Perf_Berichtsformat_SigD – Operationen des Performance-Berichts SigD

    $operation
    Produkttyp
    Operation
    Beschreibung
    SigD.sign_Data
    SigD
    sign_Data
    Bei Aufruf der Operation sign_Data beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum ePA-Client.

    Tabelle 79: Tab_gemSpec_Perf_Berichtsformat_SGD – Operationen des Performance-Berichts SGD

    $operation
    Produkttyp
    Operation
    Beschreibung
    SGD.getPublicKey
    SGD
    getPublicKey
    Bei Aufruf der Operation getPublicKey beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum ePA-Client.
    SGD.getAuthenticationToken SGD getAuthenticationToken Bei Aufruf der Operation getAuthenticationToken beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum ePA-Client.
    SGD.KeyDerivation
    SGD
    KeyDerivation
    Bei Aufruf der Operation KeyDerivation beginnt die Messung mit Annahme der Nachricht an der Außenschnittstelle des Produkttyps und endet mit dem Versand der Antwort an der Außenschnittstelle zum ePA-Client.

    Tabelle 80: Tab_gemSpec_Perf_Berichtsformat_KOM-LE – Operationen des Performance-Berichts_KOM-LE

    $operation Produkttyp-Komponente Operation Beschreibung
    I_Message_Service::send_Message FD-KOM-LE-Mail-Server send_Message Bei Aufruf der Operation send_Message beginnt die Messung mit dem Zeitpunkt der quittierten Übergabe vom KOM-LE Clientmodul an den KOM-LE Fachdienst des E-Mail-Senders und endet mit dem Zeitpunkt der quittierten Übergabe an den KOM-LE Fachdienst des E-Mail-Empfängers.
    I_Message_Service::receive_Message FD-KOM-LE-Mail-Server  receive_Message Bei Aufruf der Operation receive_Message beginnt die Messung mit dem Zeitpunkt der Annahme der Operation an der Außenschnittstelle des Produkttyps und endet mit dem Zeitpunkt der quittierten Übergabe der Nachricht an den KOM-LE Clientmodul des E-Mail-Empfängers. 
    I_Attachment_Service::add_Attachment FD-KOM-LE-KAS add_Attachment Bei Aufruf der Operation add_Attachment beginnt die Messung mit Annahme des Anhangs an der Außenschnittstelle des Produkttyps und endet mit dem quittierten Versand der Antwort an der Außenschnittstelle zum KOM-LE-Client.
    I_Attachment_Service::read_Attachment FD-KOM-LE-KAS read_Attachment Bei Aufruf der Operation read_Attachment beginnt die Messung mit der Anfrage des KOM-LE-Clients an der Außenschnittstelle des Produkttyps und endet mit dem quittierten Ende des Versands des Anhangs bzw. der Anhänge.

    Tabelle 81: Tab_gemSpec_Perf_Berichtsformat_Intermediär VSDM – Operationen des Performance-Berichts Intermediär VSDM

    $operation Produkttyp Operation/ ServiceType Beschreibung
    Intermediaer_VSDM.UFS Intermediaer-VSDM
    UFS Die Messung der Bearbeitungszeit beginnt mit Empfang der Anfrage vom Client, wird mit der Weiterleitung an den Fachdienst VSDM pausiert, läuft mit Erhalt der Antwort vom Fachdienst VSDM weiter und endet mit dem Versand der Antwort an den Client.
    Intermediaer_VSDM.VSD Intermediaer-VSDM VSD Die Messung der Bearbeitungszeit beginnt mit Empfang der Anfrage vom Client, wird mit der Weiterleitung an den Fachdienst VSDM pausiert, läuft mit Erhalt der Antwort vom Fachdienst VSDM weiter und endet mit dem Versand der Antwort an den Client. 
    Intermediaer_VSDM.CMS Intermediaer-VSDM CMS Die Messung der Bearbeitungszeit beginnt mit Empfang der Anfrage vom Client, wird mit der Weiterleitung an den Fachdienst VSDM pausiert, läuft mit Erhalt der Antwort vom Fachdienst VSDM weiter und endet mit dem Versand der Antwort an den Client. 

    Tabelle 82: Tab_gemSpec_Perf_Berichtsformat_TI-Messenger-Fachdienst <3

    Messung am Produkt $TIM-Operation
    (Referenz Use Case / Anwendungsfall)
    Beschreibung Start der Messung Ende der Messung (siehe Hinweis *1)
    TI-Messenger-Fachdienst  TIM.UC_10103_01 6.1 AF - Authentisieren einer Organisation am TI-Messenger-Dienst:
    Redirect to IdP 
    Request:
    POST /register
    (Frontend des Registrierungs-Dienstes an Registrierungs-Dienst) 
    Response:
    Redirect to IDP Authorization Endpoint
    (Antwort an Frontend des Registrierungs-Dienstes)
    TI-Messenger-Fachdienst  TIM.UC_10103_02 6.1 AF - Authentisieren einer Organisation am TI-Messenger-Dienst:
    Authentisierung 
    Request:
    POST /register (Authorization code)
    (Frontend des Registrierungs-Dienstes an Registrierungs-Dienst) 
    Response:
    status, id_token (Antwort an Frontend des Registrierungs-Dienstes)
    TI-Messenger-Fachdienst  TIM.UC_10103_03 6.1 AF - Authentisieren einer Organisation am TI-Messenger-Dienst:
    Admin Account anlegen
    Request:
    POST /register (id_token, Client-Credentials)
    (Frontend des Registrierungs-Dienstes an Registrierungs-Dienst) 
    Response:
    status, Admin-Account
    (Antwort an Frontend des Registrierungs-Dienstes)
    TI-Messenger-Fachdienst  TIM.UC_10060_01 6.2 AF - Bereitstellung eines Messenger-Service für eine Organisation:
    Login 
    Request:
    POST /login (Client-Credentials)
    (Frontend des Registrierungs-Dienstes an Registrierungs-Dienst) 
    Response:
    status
    (Antwort an Frontend des Registrierungs-Dienstes)
    TI-Messenger-Fachdienst  TIM.UC_10060_02 6.2 AF - Bereitstellung eines Messenger-Service für eine Organisation:
    Messenger-Service erstellen
    Request:
    POST /create (Matrix-Domain)
    (Frontend des Registrierungs-Dienstes an Registrierungs-Dienst)
    Response von Messenger-Service:
    status
    (Antwort an Registrierungs-Dienstes)
    TI-Messenger-Fachdienst  TIM.UC_10060_03 6.2 AF - Bereitstellung eines Messenger-Service für eine Organisation:
    Messenger-Service in die Föderation aufnehmen 
    Request:
    POST /token (client_id)
    (Registrierungs-Dienst an OAuth-Service des VZD-FHIR-Directory)
    Response:
    status
    (Antwort an Frontend des Registrierungs-Dienstes)
    TI-Messenger-Fachdienst TIM.UC_10057_01 6.4 AF - Anmeldung eines Akteurs am Messenger-Service:
    Client-Login, Auswahl Authentifizierungsverfahren
    Request:
    GET /_matrix/client/login
    (TI-Messenger-Client an Messenger-Proxy)
    Response:
    HTTPS Forward inkl. unterstützte Authentifizierungsverfahren
    (Antwort an TI-Messenger-Client)
    TI-Messenger-Fachdienst TIM.UC_10057_02 6.4 AF - Anmeldung eines Akteurs am Messenger-Service:
    Erstellung Matrix-ACCESS_TOKEN
    Request:
    POST /_matrix/client/login
    (TI-Messenger-Client an Messenger-Proxy)
    Response:
    HTTPS Forward inkl. Matrix-ACCESS_TOKEN, device_ID, MXID
    (Antwort an TI-Messenger-Client)
    TI-Messenger-Fachdienst TIM.UC_10057_03 6.4 AF - Anmeldung eines Akteurs am Messenger-Service:
    Erstellung Matrix-OpenID-Token
    Request:
    POST /_matrix/client/user/{userid}/openid/request_token
    (TI-Messenger-Client an Messenger-Proxy)
    Response:
    HTTPS Forward inkl. Matrix-OpenID-Token
    (Antwort an TI-Messenger-Client)
    TI-Messenger-Fachdienst TIM.UC_10104_01 6.7 AF - Einladung von Akteuren innerhalb einer Organisation:
    Akteur suchen
    Request:
    POST /_matrix/client/user_directory/search
    (TI-Messenger Client A an Messenger-Proxy)
    Response:
    HTTPS Forward inkl MXID
    (Messenger-Proxy an TI-Messenger Client A)
    TI-Messenger-Fachdienst TIM.UC_10104_02 6.7 AF - Einladung von Akteuren innerhalb einer Organisation:
    Akteur einladen
    Request:
    POST /_matrix/client/r0/rooms/{roomId}/invite
    (TI-Messenger Client A an Messenger-Proxy)
    Response:
    status
    (Messenger-Proxy an TI-Messenger-Client Akteur A)
    TI-Messenger-Fachdienst TIM.UC_10063_01 6.8 AF - Austausch von Events innerhalb einer Organisation Request:
    Matrix-Request
    (TI-Messenger Client an Messenger-Proxy)
    Response:
    HTTPS Forward Status (Matrix-Request)
    (Antwort an TI-Messenger-Client Akteur A)
    TI-Messenger-Fachdienst TIM.UC_10061_01 6.9 AF - Einladung von Akteuren außerhalb einer Organisation:
    Eintrag in Freigabeliste erzeugen
    Request:
    POST /tim-contact-mgmt/createContactSetting (MXID, start, end, Matrix-OpenID-Token)
    (TI-Messenger-Client an TI-Messenger Proxy)
    Response:
    status
    (Antwort an TI-Messenger-Client)
    TI-Messenger-Fachdienst (Sendersystem) TIM.UC_10061_02 6.9 AF - Einladung von Akteuren außerhalb einer Organisation:
    Einladung Sendersystem
    Request:
    POST /_matrix/client/r0/rooms/{roomId}/invite
    (TI-Messenger Client an Messenger-Proxy)
    Response:
    HTTPS Forward Status
    (Antwort an TI-Messenger-Client Akteur A)

    TI-Messenger-Fachdienst (Sendersystem) TIM.UC_10061_03 6.9 AF - Einladung von Akteuren außerhalb einer Organisation:
    Einladung Empfangssystem(e)
    Request:
    HTTPS Forward (POST /_matrix/federation/v1/invite/{roomId}/{eventId})
    (Messenger-Proxy des Sendersystems an Messenger-Proxy des Empfangssystems)
    Response:
    Status
    (Antwort an Messenger-Proxy des Sendersystems)
    TI-Messenger-Fachdienst (Sendersystem) TIM.UC_10062_01 6.10 AF - Austausch von Events zwischen Akteuren außerhalb einer Organisation:
    Event Sendersystem
    Request:
    Matrix-Request
    (TI-Messenger Client an eigenen Messenger-Proxy)
    Response:
    HTTPS Forward Status
    (Antwort an TI-Messenger-Client Akteur A
    TI-Messenger-Fachdienst (Sendersystem) TIM.UC_10062_02 6.10 AF - Austausch von Events zwischen Akteuren außerhalb einer Organisation:
    Event Empfangssystem(e)
    Request:
    HTTPS Forward Matrix-Request
    (Messenger-Proxy Sendersystem an Messenger-Proxy Empfangssystem)
    Response:
    HTTPS Forward Status
    (Antwort an Messenger-Proxy des Sendersystems)

    9 Anhang D – Performancerelevante Produktmustereigenschaften des QES-Konnektors

    Im Folgenden werden die erforderlichen, performance-relevanten Produktmustereigenschaften des QES-Konnektors festgelegt, auf deren Basis die zum Nachweis von [GS-A_5327] erforderlichen Performance-Messungen durchgeführt werden können.

    Entsprechend der Lastvorgaben aus [GS-A_5327] für 8 Anwendungen wird das Messverfahren festgelegt. Auf Grund der unterschiedlichen Lastanforderungen für die beiden Ausprägungsformen „Einbox-Konnektor“ und „HighSpeed-Konnektor“ wird das Verfahren für beide Fälle dargestellt.

    Aus den Lastvorgaben in Tab_gemSpec_Perf_Konnektor und dem Skalierungsfaktor 8/3 wird die perspektivische Last für 8 Anwendungen berechnet. Dabei werden jeweils Operationen mit 25MB-Dokumenten und Operationen mit 100kB-Dokumenten als eine Klasse betrachtet. Die Wahrscheinlichkeit, dass n parallele Bearbeitungen zu einem Zeitpunkt stattfinden, ergibt sich als Poisson-Verteilung mit dem Erwartungswert „Last * Mittlere Bearbeitungszeit“.


    Einbox-Konnektor

    Tabelle 83: Tab_gemSpec_Perf_Einbox_Konnektor_Last_8_Anwendungen






    Wahrscheinlichkeit für
    n parallele Aufrufe
    zu einem Zeitpunkt

    Last
    [1/h]
    Last
    *8/3
    [1/h]
    Mittlere
    Bearb.z.



    [ms]
    Last
    * Mittlere Bearb.z.
    [Anzahl]
    0
    1
    2
    3
    4
    I_Sign_Operations::
    sign_Document (100 kB, LE-U2)
    389
    1037
    840
    0,24
     
     
     
     
     
    I_Sign_Operations::
    sign_Document (25 MB)
    13
    35
    7300
    0,07
     



     
    I_Sign_Operations::
    verify_Document (100 kB, LE-U2)
    297
    792
    1430
    0,31
     



     
    I_Sign_Operations::
    verify_Document (25 MB)
    13
    35
    7900
    0,08
     



     
    I_Crypt_Operations::
    encrypt_Document (100 kB, LE-U2)
    258
    688
    1880
    0,36
     



     
    I_Crypt_Operations::
    encrypt_Document (25 MB)
    13
    35
    6700
    0,07
     



     
    I_Crypt_Operations::
    decrypt_Document (100 kB, LE-U2)
    258
    688
    510
    0,10
     



     
    I_Crypt_Operations::
    decrypt_Document (25 MB)
    13
    35
    8900
    0,09
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    Operationen 25 MB Dokument
    52
    140
    7700
    0,30
    74%
    22%
    3%
    0%
    0%
    Operation 100 kB Dokument
    1202
    3205
    1165
    1,04
    35%
    37%
    19%
    7%
    2%


    In der Lastsituation für 8 Anwendungen ergeben sich verschiedene Situationen in Bezug auf die parallele Bearbeitung von Anfragen, dargestellt in Tabelle "Tab_gemSpec_Perf_Einbox_Konnektor_Lastsituationen". In Situation 1 bearbeitet der Konnektor weder Operationen mit 25 MB-Dokumenten noch solche mit 100kB-Dokumenten. In den Situationen 2 und 5 bearbeitet der Konnektor genau jeweils ein Dokument. In den übrigen Situationen liegt parallele Verarbeitung vor.

    Tabelle 84: Tab_gemSpec_Perf_Einbox_Konnektor_Lastsituationen

    Lastsituationen i
    i
    Parallele Bearbeitungen
    mit 25 MB Dokumenten
    [Anzahl]
    Parallele Bearbeitungen
    mit 100 kB Dokumenten
    [Anzahl]
    Wahrscheinlichkeit
    pi
    1
    0
    0
    26%
    2
    0
    1
    27%
    3
    0
    2
    14%
    4
    0
    3
    5%
    5
    1
    0
    8%
    6
    1
    1
    8%
    7
    1
    2
    4%
    8
    1
    3
    1%

    Für jede der Lastsituationen in Tab_gemSpec_Perf_Einbox_Konnektor_Lastsituationen ist eine Messreihe zu erstellen. In jeder Messreihe sind vom Clientsystem jeweils ein Aufruferthread pro parallele Bearbeitung zu starten, der 100mal sign_Document, encrypt_Document, decrypt_Document und verify_Document sequentiell, direkt nacheinander aufruft. In Lastsituation 8 sind es beispielsweise 1 Thread, der 25 MB große Dokumente bearbeitet, und 3 Threads, die 100 kB große Dokumente bearbeiten.

    Für jede der Lastsituationen i und der Operationen sind die Mittelwerte der Bearbeitungszeiten für die beiden Klassen 25MB-Dokumente und 100kB-Dokumente zu bestimmen.

    Durch den Test ist nachzuweisen, dass die über die Lastsituationen gemittelte Bearbeitungszeit für jede Operation kleiner als die vorgegebene Bearbeitungszeit gemäß Tab_gemSpec_Perf_Einbox_Konnektor_Last_8_Anwendungen ist:




    wird für 100 kB Dokumente wie folgt gemittelt:




    wird für 25 MB Dokumente wie folgt gemittelt:




    HighSpeed-Konnektor

    Tabelle 85: Tab_gemSpec_Perf_HighSpeed_Konnektor_Last_8_Anwendungen






    Wahrscheinlichkeit für
    n parallele Aufrufe
    zu einem Zeitpunkt

    Last
    [1/h]
    Last
    *8/3
    [1/h]
    Mittlere
    Bearb.z.



    [ms]
    Last
    * Mittlere Bearb.z.
    [Anzahl]
    0
    1
    2
    3
    4
    5
    6
    7
    I_Sign_Operations::
    sign_Document
    (100 kB, LE-U4)
    1459
    3891
    840
    0,91
     
     
     
     
     
     
     
     
    I_Sign_Operations::
    sign_Document
    (25 MB)
    13
    35
    7300
    0,07
     






     
    I_Sign_Operations::
    verify_Document
    (100 kB, LE-U4)
    857
    2285
    1430
    0,91
     






     
    I_Sign_Operations::
    verify_Document
    (25 MB)
    13
    35
    7900
    0,08
     






     
    I_Crypt_Operations::
    encrypt_Document
    (100 kB, LE-U4)
    575
    1533
    1880
    0,80
     






     
    I_Crypt_Operations::
    encrypt_Document
    (25 MB)
    13
    35
    6700
    0,06
     






     
    I_Crypt_Operations::
    decrypt_Document
    (100 kB, LE-U4)
    575
    1533
    510
    0,22
     






     
    I_Crypt_Operations::
    decrypt_Document
    (25 MB)
    13
    35
    8900
    0,09
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    Operationen mit
    25 MB Dokument
    52
    139
    7700
    0,30
    74%
    22%
    3%
    0%
    0%
    0%
    0%
    0%
    Operationen mit
    100 kB Dokument
    3466
    9243
    1165
    2,99
    5%
    15%
    22%
    22%
    17%
    10%
    5%
    2%

    In der Lastsituation für 8 Anwendungen ergeben sich verschiedene Situationen in Bezug auf die parallele Bearbeitung von Anfragen, dargestellt in Tabelle "Tab_gemSpec_Perf_HighSpeed_Konnektor_Lastsituationen".

    Tabelle 86: Tab_gemSpec_Perf_HighSpeed_Konnektor_Lastsituationen

    Situationen i
    i
    Parallele Bearbeitungen
    mit 25 MB Dokumenten
    [Anzahl]
    Parallele Bearbeitungen
    mit 100 kB Dokumenten
    [Anzahl]
    Wahrscheinlichkeit
    pi
    1
    0
    0
    4%
    2
    0
    1
    11%
    3
    0
    2
    17%
    4
    0
    3
    17%
    5
    0
    4
    12%
    6
    0
    5
    7%
    7
    0
    6
    4%
    8
    0
    7
    2%
    9
    1
    0
    1%
    10
    1
    1
    3%
    11
    1
    2
    5%
    12
    1
    3
    5%
    13
    1
    4
    4%
    14
    1
    5
    2%
    15
    1
    6
    1%
    16
    2
    3
    3%

    Für jede der Lastsituationen i in Tab_gemSpec_Perf_HighSpeed_Konnektor_Lastsituationen ist eine Messreihe zu erstellen. In jeder Messreihe sind vom Clientsystem jeweils ein Aufruferthread pro parallele Bearbeitung zu starten, der 100 mal sign_Document, encrypt_Document, decrypt_Document und verify_Document sequentiell, direkt nacheinander aufruft. In Lastsituation 16 sind es beispielsweise 2 Threads, die 25 MB große Dokumente bearbeiten, und 3 Threads, die 100 kB große Dokumente bearbeiten.

    Für jede der Lastsituationen i und die Operationen sind die Mittelwerte der Bearbeitungszeiten für die beiden Klassen 25 MB-Dokumente und 100 kB-Dokumente zu bestimmen.

    Durch den Test ist nachzuweisen, dass die über die Lastsituationen gemittelte Bearbeitungszeit für jede Operation kleiner als die vorgegebene Bearbeitungszeit gemäß Tab_gemSpec_Perf_HighSpeed_Konnektor_Last_8_Anwendungen ist:




    wird für 100 kB Dokumente wie folgt gemittelt:




    wird für 25 MB Dokumente wie folgt gemittelt:



    Rahmenbedingungen

    Folgende konkretisierende Rahmenbedingungen gelten für Einbox-Konnektoren und HighSpeed-Konnektoren gleichermaßen:

    Weichen die in den Messungen durchgeführten Rahmenbedingungen hiervon ab, müssen die Werte entsprechend auf diese Rahmenbedingungen korrigiert werden.

    10 Anhang E – Testverfahren zur Prüfung der Skalierungsfähigkeit des QES-Konnektors

    Entsprechend der Lastvorgaben aus [GS-A_5327] für 8 Anwendungen wird das Messverfahren festgelegt. Auf Grund der unterschiedlichen Lastanforderungen für die beiden Ausprägungsformen „Einbox-Konnektor“ und „HighSpeed-Konnektor“ wird das Verfahren für beide Fälle dargestellt. Für beide Ausprägungsformen werden die Signaturverfahren CAdES, XAdES, PAdES und die Verschlüsselungsverfahren XMLEnc und CMS unterschieden.

    Es gelten die Bearbeitungszeitvorgaben aus Tabelle "Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben".

    Tabelle 87: Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben


    Mittlere Bearbeitungszeit


    [ms]

    CMS,
    CAdES
    XMLEnc,
    XAdES
    CMS,
    PAdES
    I_Sign_Operations::sign_Document (100 kB)
    1100
    1100
    1100
    I_Sign_Operations::sign_Document (25 MB)
    7300
    10500
    7300
    I_Sign_Operations::verify_Document (100 kB)
    500
    500
    500
    I_Sign_Operations::verify_Document (25 MB)
    7900
    7900
    9500
    I_Crypt_Operations::encrypt_Document (100 kB)
    780
    780
    780
    I_Crypt_Operations::encrypt_Document (25 MB)
    6700
    9500
    6700
    I_Crypt_Operations::decrypt_Document (100 kB)
    510
    510
    510
    I_Crypt_Operations::decrypt_Document (25 MB)
    8900
    8900
    8900


    Einbox-Konnektor

    In der Lastsituation für 8 Anwendungen ergeben sich verschiedene Situationen in Bezug auf die parallele Bearbeitung von Anfragen, dargestellt in Tabelle "Tab_gemSpec_Perf_Einbox_QES-Konnektor_Lastsituationen". In Situation 1 bearbeitet der Konnektor weder Operationen mit 25-MB-Dokumenten noch solche mit 100-kB-Dokumenten. In den Situationen 2 und 5 bearbeitet der Konnektor genau jeweils ein Dokument. In den übrigen Situationen liegt parallele Verarbeitung vor.

    Die Situationen sind getrennt für die folgenden drei Verfahrensgruppen zu betrachten:

    Tabelle 88: Tab_gemSpec_Perf_Einbox_QES-Konnektor_Lastsituationen

    Situationen i
    i
    25 MB
    [Anzahl]
    100 kB
    [Anzahl]
    Wahrscheinlichkeiten pi
    CMS,
    CAdES
    XMLEnc,
    XAdES
    CMS,
    PAdES
    1
    0
    0
    39
    37
    38
    2
    0
    1
    25
    24
    25
    3
    0
    2
    8
    8
    8
    4
    0
    3
    2
    2
    2
    5
    1
    0
    12
    13
    12
    6
    1
    1
    7
    8
    8
    7
    1
    2
    2
    3
    2

    Für jede der Lastsituationen i in Tab_gemSpec_Perf_Einbox_QES-Konnektor_Lastsituationen ist eine Messreihe zu erstellen. In jeder Messreihe sind vom Clientsystem jeweils ein Aufruferthread pro parallele Bearbeitung zu starten, der 100mal sign_Document, encrypt_Document, decrypt_Document und verify_Document sequentiell, direkt nacheinander aufruft. In Lastsituation 7 sind es beispielsweise 1 Thread, der 25 MB große Dokumente bearbeitet, und 2 Threads, die 100 kB große Dokumente bearbeiten.

    Für jede der Lastsituationen i und der Operationen sind die Mittelwerte der Bearbeitungszeiten für die beiden Klassen 25-MB-Dokumente und 100-kB-Dokumente zu bestimmen.

    Durch den Test ist pro Verfahrengruppe nachzuweisen, dass die über die Lastsituationen gemittelte Bearbeitungszeit für jede Operation kleiner als die vorgegebene Bearbeitungszeit gemäß Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben ist:




    wird für 100-kB-Dokumente wie folgt gemittelt:




    wird für 25-MB-Dokumente wie folgt gemittelt:



    HighSpeed-Konnektor

    In der Lastsituation für 8 Anwendungen ergeben sich verschiedene Situationen in Bezug auf die parallele Bearbeitung von Anfragen, dargestellt in Tabelle "Tab_gemSpec_Perf_HighSpeed_QES-Konnektor_Lastsituationen".

    Tabelle 89: Tab_gemSpec_Perf_HighSpeed_QES-Konnektor_Lastsituationen

    Situationen i
    i
    25 MB
    [Anzahl]
    100 kB
    [Anzahl]
    Wahrscheinlichkeiten pi
    CMS,
    CAdES
    XMLEnc,
    XAdES
    CMS,
    PAdES
    1
    0
    0
    12
    11
    14
    2
    0
    1
    22
    21
    23
    3
    0
    2
    20
    20
    19
    4
    0
    3
    12
    12
    11
    5
    0
    4
    6
    6
    5
    6
    0
    5
    2
    2
    2
    7
    1
    0
    3
    4
    4
    8
    1
    1
    6
    7
    7
    9
    1
    2
    6
    6
    6
    10
    1
    3
    4
    4
    3
    11
    1
    4
    2
    2
    1
    12
    2
    2
    3
    4
    4

    Für jede der Lastsituationen i in Tab_gemSpec_Perf_HighSpeed_QES-Konnektor_Lastsituationen ist eine Messreihe zu erstellen. In jeder Messreihe sind vom Clientsystem jeweils ein Aufruferthread pro parallele Bearbeitung zu starten, der 100 mal sign_Document, encrypt_Document, decrypt_Document und verify_Document sequentiell, direkt nacheinander aufruft. In Lastsituation 12 sind es beispielsweise 2 Threads, die 25 MB große Dokumente bearbeiten, und 2 Threads, die 100 kB große Dokumente bearbeiten.

    Für jede der Lastsituationen i und die Operationen sind die Mittelwerte der Bearbeitungszeiten für die beiden Klassen 25 MB-Dokumente und 100 kB-Dokumente zu bestimmen.

    Durch den Test ist nachzuweisen, dass die über die Lastsituationen gemittelte Bearbeitungszeit für jede Operation kleiner als die vorgegebene Bearbeitungszeit gemäß Tab_gemSpec_Perf_QES-Konnektor_Skalierungsfähigkeit_Bearbeitungszeitvorgaben ist:




    wird für 100 kB Dokumente wie folgt gemittelt:




    wird für 25 MB Dokumente wie folgt gemittelt:



    Rahmenbedingungen

    Folgende konkretisierende Rahmenbedingungen gelten für Einbox-Konnektoren und HighSpeed-Konnektoren gleichermaßen zusätzlich zu den generellen Rahmenbedingungen für die Messungen aus Kapitel 4.1.2: